0

I've been working on a project to build a windows executable file using mingw-w64. I decided I wanted to test out using libtins for the project and downloaded the library file (.lib) from libtins' website. The .lib file compiled using VisualStudio2015. I wanted to statically link the library and linking failed to resolve the undefined references I was using. I later found out, by using nm on the library file, that VisualStudio2015 mangles the symbols differently than MinGW. So I then compiled libtins from source using MinGW. However, the undefined references continued to fail to resolve after trying to link with the newly compiled library. Using nm I could see that the undefined symbols in my object files matched the needed symbols found in the library yet, the files failed to link into an executable file. I then used ar to extract the object files from the library and slowly added the required object files and eventually the executable linked and ran fine.

I also found this answer and linking the whole archive also succeeded. What circumstances would cause an issue like this? I can link to the individual object files but not the library archive that holds these files, or I can link to the whole archive but not to the individual compontents within it. What can explain this behavior?

Edit:

linking fails with this command

/usr/local/Cellar/mingw-w64/5.0.3/bin/i686-w64-mingw32-g++ -static -L/usr/local/Cellar/mingw-w64/5.0.3/toolchain-i686/mingw/lib -L../../libtins/lib -L../../wpcap/Lib/ -o dist/test.exe obj/main.o obj/test.o -ltins -liphlpapi -lwpcap -lws2_32 -lpthread -lntdll -lmsvcrt -lstdc++
KDavis
  • 63
  • 1
  • 1
  • 6
  • Probably [Your linkage consumes libraries before the object files that refer to them](https://stackoverflow.com/a/43305704/1362568) explains the original failing linkage, but you haven't shown us what it was so we can't be sure. Linking `--whole-archive` would overcome wrong linkage order at the cost of linking possibly unnecessary object files. – Mike Kinghan Dec 05 '17 at 08:38
  • @MikeKinghan Thanks for your comment. I've added the failing linkage line. And yes, using the --whole-archive directive creates a much larger executable file as a result of all the unnecessary object files being thrown in. The references to the undefined methods to libtins are located in obj/test.o. because libtins is after obj/test.o in the link order, shouldn't those undefined references be resolved as the linker looks through the tins library for the missing references? – KDavis Dec 07 '17 at 00:17

0 Answers0