Hi Thiago, > On Apr 29, 2020, at 8:48 PM, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > On Wednesday, 29 April 2020 15:16:49 PDT Ben Haller via Interest wrote: >> -ltskit -lQt5OpenGL -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread >> >> And here’s the beginning of the link errors, of which there are a fair >> number: >> >> /home/bhaller/Desktop/SLiM_QMAKE_5142/QtSLiM/../eidos//libeidos.a(eidos_glob >> als.o): In function `_Eidos_FlushZipBuffer(std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> > const&, >> std::__cxx11::basic_string<char, std::char_traits<char>, >> std::allocator<char> > const&)': >> eidos_globals.cpp:(.text+0x432): undefined reference to `z_gzopen' >> eidos_globals.cpp:(.text+0x44f): undefined reference to `z_gzbuffer' >> eidos_globals.cpp:(.text+0x461): undefined reference to `z_gzwrite' >> eidos_globals.cpp:(.text+0x474): undefined reference to `z_gzclose_w' > > -lz is missing on your linker command-line.
These symbols are brought in with -leidos_zlib, an internal library. >> chromosome.cpp:(.text+0x3f): undefined reference to `gsl_ran_discrete_free' >> chromosome.cpp:(.text+0x4d): undefined reference to `gsl_ran_discrete_free' >> chromosome.cpp:(.text+0x5b): undefined reference to `gsl_ran_discrete_free' >> chromosome.cpp:(.text+0x69): undefined reference to `gsl_ran_discrete_free' >> chromosome.cpp:(.text+0x77): undefined reference to `gsl_ran_discrete_free’ > > Some other library also missing. I don't have this symbol in any library on > my > system so I can't offer you a suggestion. Please consult the its > documentation > (since you're using it, you must know it) and figure out what it is called so > you can link. > > Though I do note you have -lgsl on your linker line. If this is the right > library, then check if the library has those symbols (nm -D if it's an .so, > nm > if it's .a). These are brought in with -lgsl, another internal library. >> gsl: a statically linked C library (an edited version of the GNU GSL >> library) >> eidos_zlib: a statically linked C library (an edited version of the standard >> zlib library) > > If libraries are static, the order in the linker command-line matters. The > library must appear after the object that requires it. > > For example, for: > obj.o -lA -lB > > obj.o can depend on libA.a and libB.a; libA.a can depend on libB.a. > > libB.a cannot depend on libA.a Aha! And I figured out that the order in which I declare the dependencies in my .pro file determines the order in which those dependencies appear in the link command. I fixed that, and now it builds. I guess this was not biting me before because I used to link these internal libraries dynamically instead; perhaps the link order is not important with dynamic linking? So when I recently changed to static linking for these internal libraries, the link order suddenly mattered, and my build broke. And I guess perhaps the linker on macOS doesn’t have this requirement, and so the build continued to work there? Anyway, problem solved, wonderful. Thank you, Thiago! Cheers, -B. Benjamin C. Haller Messer Lab Cornell University _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
