[Interest] Link failure with undefined references, on Ubuntu but not macOS
Ben Haller
bhaller at mac.com
Thu Apr 30 03:57:24 CEST 2020
Hi Thiago,
> On Apr 29, 2020, at 8:48 PM, Thiago Macieira <thiago.macieira at 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
More information about the Interest
mailing list