But what exactly happens now? What is the error?
There is no error, it simply crashes ld, i.e. the linker itself.
With MinGW 4.9. that has some debug info enabled we got the following assert:
c:/dev/mingw32-49posixsjlj/bin/../lib/gcc/i686-w64-mingw32/4.9.0/../../../../i686-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.23.2 assertion fail ../../../src/binutils-2.23.2/bfd/cofflink.c:2389
Which then leads to the source code like:
/* Write the modified symbols to the output file. */
if (outsym > flaginfo->outsyms)
{
file_ptr pos;
bfd_size_type amt;
pos = obj_sym_filepos (output_bfd) + syment_base * osymesz;
amt = outsym - flaginfo->outsyms;
if (bfd_seek (output_bfd, pos, SEEK_SET) != 0
|| bfd_bwrite (flaginfo->outsyms, amt, output_bfd) != amt)
return FALSE;
BFD_ASSERT ((obj_raw_syment_count (output_bfd)
+ (outsym - flaginfo->outsyms) / osymesz)
== output_index);
obj_raw_syment_count (output_bfd) = output_index;
}
It just seems ld can't deal with having two different libraries that include both the same library, thus when trying to extract them into the binary (linking static etc.) it might come in a conflict of trying to write the same library data twice or something like that. Just random guessing why ld crashes.
Thus the real issue here is, that SFML is extracting the object files and includes them into SFML's library, instead of letting the user link everything statically in the final step, like how static linking should be done!
Making only sfml-system link to winmm, will resolve the crashing, since there will only be one version of winmm, but it won't fix the wrong way of linking static dependencies...