Re: Symbol versioning in dlopen modules

[Zoltan Hidvegi <hzoli at austin dot ibm dot com>]

H . J . Lu wrote:
> Yes, it should work. It is similar to
> 
> http://sources.redhat.com/ml/libc-alpha/2000-11/msg00260.html
> http://sources.redhat.com/ml/binutils/2000-11/msg00108.html
> 
> You may have to use my Linux binutils to do it.

I have used GNU ld version 2.12.90.0.7 20020423 Debian GNU/Linux from
Debian unstable, ld-linux.so.2 from the Debian unstable glibc-2.2.5
package, but it does not work, I attached the small example I have
tried.  Just unpack it and run make, it will build main, lib1.so,
lib2.so and lib3.so, and it will run main.  lib1.so and lib2.so are
identical except that in the function names and messages lib1 is
replaced by lib2.  main, lib1 and lib2 exports message with a version,
and in lib3 I am trying to pick up the version of message from lib2,
but it instead gets it from lib1.

I wish there were a way to link a dlopen module with a `fake' shared
library, that has all the symbols expored by the main application with
the right version number.  Linking against the fake library would
allow the linker to pick up the symbol version from the lbrary, but
the fake library would not actually appear as a dependency in the
dynamic section, so it would not be loaded when I dlopen the module.
The other nice feature is that this would allow the use of the
--no-undefined linker flag, so that the linker could stop if there are
any undefined references not resolved by the API exported from main.

There are other things which seem to be real bugs.  If I remove the
message definitions from lib1 and lib2, they will not load because the
dynamic loader does not see the version of message defined in main.
It looks like the @@ versions defined in main are not visible in the
loaded modules.

The other problem may be not really a bug.  Normally on x86 Linux I
can compile dynamically loadable objects without -fPIC, and they work
just fine, the only bad side-effect is that they will not be properly
shared, since the relocations make the text pages dirty.  But if I
link lib1.so or lib2.so without -fPIC, the run-time linker will not
relocate the last function call in lib1() or lib2() and I get an
illegal instruction coredump.  If I remove the call to message() in
lib1 and lib2, then the non-pic version will work, so this is somehow
related to versioning.

Zoli

Attachment: symver.tar.gz
Description: /tmp/symver.tar.gz