Can a shared object library access objects from a statically linked library?

Question

I have an application which contains a statically linked library (libUtils.a).

I turned a library which i previously had linked statically into a shared object library. This library (SheepPopWapper.so) also needs access to some of the functions in libUtils.a.

When i run my application i get a runtime error:

[DynPopFactory::collectPlugins] Couldn't open so [/home/jody/progs/QHG4/dynpops/so_dir/SheepPopWrapper.so]: /home/jody/progs/QHG4/dynpops/so_dir/SheepPopWrapper.so: undefined symbol: _ZN10MessLogger17s_sCurHeaderErrorB5cxx11E

The Object MessLogger is in libUtils.a and is visible in the application:

 $ nm  MainAppDyn | grep MessLogger17s
000000000026d7e0 B _ZN10MessLogger17s_sCurHeaderErrorB5cxx11E

However, if i link libUtils.a to SheepPopWrapper.so, everything works as expected.

But somehow it bothers me that during run time there are two copies of libUtils. This situation also caused an actual problem because libUtils contains an object i implemented as a singleton, and in this situation there are two singletons (one for each copy of libUtils).

So the question is: can a shared object library access objects from a statically linked object?

And if this is the case, how can this be done?

Answer 1

So the question is: can a shared object library access objects from a statically linked object?

Yes, but the symbol must be exported from the main binary (must be present in its dynamic symbol table).

You can verify that the symbol is currently not present using:

nm -D MainAppDyn | grep _ZN10MessLogger17s_sCurHeaderErrorB5cxx11E

which should produce no output.

Once you've confirmed that this is the case, you can relink MainAppDyn with -Wl,--export-dynamic flag, and confirm that the symbol becomes exported repeating the same nm -D ... command above.

This may not be the best approach though, as it makes the binary slightly bigger and dynamic linking slightly slower by exporting all symbols in the dynamic symbol table.

If you have a reasonably recent linker, using -Wl,--export-dynamic-symbol=_ZN10MessLogger17s_sCurHeaderErrorB5cxx11E may be better (this only forces this one symbol to be exported).

On the other hand, you may discover that SheepPopWrapper.so requires a lot more symbols from libUtils.a, in which case exporting them all could be a reasonable approach after all.

Update:

i got a new runtime error symbol lookup error: /home/jody/progs/QHG4/dynpops/so_dir//GrassPopWrapper.so: undefined symbol: _ZN12LBControllerC1Ev
The LBController is part of libUtils (as seen by nm) but it does not show up in an nm call for the application. Is this a consequence of smart linking?

This is a consequence of "normal" linking -- the linker doesn't pull objects into the binary unless it can see that that this symbol is being used. See this blog post to understand how the linker decides.

You can work around this by:

1. Adding -Wl,--whole-archive -lUtils -Wl,--no-whole-archive or
2. Adding -Wl,-u,_ZN12LBControllerC1Ev to the link line of MainAppDyn (repeat for each symbol that you want to force-include into the main application).

For option 1, see also this answer.