问题
I'm trying to build a shared object library that will be opened by a program using dlopen(). This library will use functionality provided by a separate library that is static.
I have included the appropriate flag on the link line to pull in the static library when linking the dynamic one (e.g. I have -lfoo for libfoo.a), and the linker doesn't complain. However, when the main program calls dlopen() on the dynamic library, the call fails with an "undefined symbol" message referencing a symbol from the static library.
Running nm does indicate that the symbol in question is undefined in the dynamic library, and the main program doesn't contain it, so how can I force the linker to pull this symbol in? The symbol itself is in the uninitialized data section (symbol type "B" in the nm output).
回答1:
The --whole-archive linker option should do this. You'd use it as e.g.
gcc -o libmyshared.so foo.o -lanothersharedlib -Wl,--whole-archive -lmystaticlib
What you're experiencing is that by default, the linker will search for symbols in a static archive that the binary you produce needs, and if it needs one, it'll include the whole .o that the symbol resides in. If your shared library doesn't need any of the symbols, they will not be included in your shared lib.
Remember that code that becomes a shared library needs to be compiled with special options, such as -fpic , as you're including a static library in your shared library, the static library needs to be compiled with the same options.
回答2:
Recently I was searching solution for the same. I found using
--undefined=symbol
or
-u symbol
solves the problem.
回答3:
Another hack is to take the address of the function somewhere during initialization of the library. This will make sure you actually use the symbol.
来源：https://stackoverflow.com/questions/7253801/how-to-force-symbols-from-a-static-library-to-be-included-in-a-shared-library-bu