问题
I am compiling a program against a shared library I have written. This library in turn relies on Boost::program_options (among other libraries). When I compile my program, I need of course to mention my library, but I get a DSO error:
g++ ism_create_conf.cc -o ism_create_conf -lglsim_ol -lglsim -lhdf5 -lgsl
/usr/bin/ld.real: /tmp/cc9mBWmM.o: undefined reference to symbol_ZN5boost15program_options8validateERNS_3anyERKSt6vectorISsSaISsEEPSsi'
//usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.55.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
I know that the error goes away if I add -lboost_program_options. What I don't understand is
Why do I have to do this even if my program does not call Boost directly (only through my glsim library).
Why does the linker want
-lboost_program_optionswhen it actually found the correct library (and location) by itself (see the second line of the error message).
The situation is similar to what was asked e.g here, but I am asking something different: I know the solution is to mention the library in the command line, I want to know why I have to do this even if the linker already knows where the library is. There is obviously something I do not understand about how shared libraries work, it seems to me that when I use other shared libraries, these libraries can automatically call other shared libraries they need. However, the shared library I built does not have this ability.
回答1:
Modern distros (e.g. Ubuntu Natty and later) enable --as-needed flag by default in their toolchains. One of side-effects is that linker tracks order of libraries more strictly (not sure why this was done, probly to match static libraries case).
来源：https://stackoverflow.com/questions/38352092/why-do-i-get-dso-missing-error-even-when-the-linker-can-locate-the-library