[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