I'm trying to learn more about library versioning in Linux and how to put it all to work. Here's the context:
-- I have two versions of a dynamic library which expose the same set of interfaces, say
-- An application is linked against
-- This application uses
libdl.so to dynamically load another module, say
libmagic.so is linked against
libsome2.so. Obviously, without using linker scripts to hide symbols in
libmagic.so, at run-time all calls to interfaces in
libsome2.so are resolved to
libsome1.so. This can be confirmed by checking the value returned by
libVersion() against the value of the macro
-- So I try next to compile and link
libmagic.so with a linker script which hides all symbols except 3 which are defined in
libmagic.so and are exported by it. This works... Or at least
LIB_VERSION values match (and it reports version 2 not 1).
-- However, when some data structures are serialized to disk, I noticed some corruption. In the application's directory if I delete
libsome1.so and create a soft link in its place to point to
libsome2.so, everything works as expected and the same corruption does not happen.
I can't help but think that this may be caused due to some conflict in the run-time linker's resolution of symbols. I've tried many things, like trying to link
libsome2.so so that all symbols are alised to
[email protected]@VER_2 (which I am still confused about because the command
nm -CD libsome2.so still lists symbols as
symbol and not
[email protected]@VER_2)... Nothing seems to work!!! Help!!!!!!
Edit: I should have mentioned it earlier, but the app in question is Firefox, and
libsqlite3.so shipped with it. I don't quite have the option of recompiling them. Also, using version scripts to hide symbols seems to be the only solution right now. So what really happens when symbols are hidden? Do they become 'local' to the SO? Does rtld have no knowledge of their existence? What happens when an exported function refers to a hidden symbol?
Try compiling both
libsome2.so to add symbol versioning, each with their own version (use the
--version-script option to
ld). Then link the application and
libmagic.so using the new libraries. Then,
libsome2.so should be completely separate.
Problems can still occur if there are unversioned references to symbols. Such references can be satisfied by versioned definitions (so that it is possible to add symbol versioning to a library without breaking binary compatibility). If there are multiple symbols of the same name, it can sometimes be hard to predict which one will be used.
nm -D does not display any information about symbol versioning. Try
objdump -T or
readelf -s instead.