共享对象中的符号

Question

My scenario is :

• frame work static lib - libFramework.a
• A shared object using that framework - mySharedObj.so
• An executable that is using both libs - myExe.elf

I am compiling the so and the elf separately. Sometimes the framework has a new version and I want to update only the so or only the elf (does'nt matter) But when I am running the application (with debug) , I see that the so is using the elf framework lib How can I "force" the so use its own framework instance while running under the elf

BTW I have the same issue if by chance the so and elf both have a class with the same name (if not using namespaces etc.) The so is using the elf class.

Answer 1

What's probably happening is that libFramework.a is exposing dynamic symbols. When you start myExe.elf, it resolves those dynamic symbols from itself (or its own copy of libFramework.a, if you want to look at it like that).

When mySharedObj.so is loaded, it then resolves all those symbols again, and finds the ones in myExe.elf rather than in mySharedObj.so, because it's reusing the result of the previous resolution. You can probably confirm this by running myExe.elf with LD_DEBUG=all, eg LD_DEBUG=all myExe.elf .

To stop this happening, you want to prevent any dynamic symbols from being exported by libFramework.a. You can use the compiler flag -fvisibility=hidden to change the default to symbols being hidden, and then make sure that your symbols aren't then being made visible again by attributes in the source code, eg __attribute__ ((visibility ("default"))) or by pushing and popping visibility #pragma GCC visibility push(default) #pragma GCC visibility pop . You can also use nm to see what symbols are being exposed as dynamic symbols.

It's also worth checking this sort of stuff out for perf reasons. If all your symbols are dynamic, the runtime dynamic linker has to do a lot more work, so your program will take longer to load. The compiler can also generate better code because it doesn't have to put in the code to let functions be called dynamically. The linker can do a better job of dead code elimination, etc. There's a bunch of wins.