A symbol version bug

["H. J. Lu" <hjl at lucon dot org>]

Michael found a bug between binutils and glibc. ld.so assumes the
first symbol from the hash table is the oldest (default) version.
Unfortunately, it is not always true. The question is if glibc
should depend on it or ld should guarantee it.


H.J.
----
On Tue, May 13, 2003 at 09:49:13PM +0200, Michael Kerrisk wrote:
Content-Description: Mail message body
> > On Fri, May 09, 2003 at 01:41:37PM +0200, Michael Kerrisk wrote:
> > > Hello HJ.,
> > > 
> > > Just to follow up on my earlier question.  Looking at the version scripts > > documentation in "info glibc", I understand well enough what the 
> > > following do:
> > > 
> > > __asm__(".symver old_foo,foo@VERS_1.1");
> > > __asm__(".symver old_foo1,foo@VERS_1.2");
> > > __asm__(".symver new_foo,foo@@VERS_2.0");
> > > 
> > > But there is also this example mentioned:
> > > 
> > > __asm__(".symver original_foo,foo@");
> > > 
> > > And the following text 
> > > 
> > > > In this example, `foo@' represents the symbol `foo' bound to the 
> > > > unspecified base version of the symbol. The source file that contains
> > > > this example would define 4 C functions: `original_foo', `old_foo',
> > > > `old_foo1', and `new_foo'.
> > > 
> > > However, I can't seem to find anything that usefully works with the foo@
> > > syntax.  Do you know / could you explain to me where and when this syntax > > is useful?
> > > 
> > > I tried the following (unsuccessful) experiment:
> > 
> > It works for me. Here is my example.
> > 
> > # make
> > cc    -c -o new.o new.c
> > cc -Wl,-soname,libfoo.so,--version-script=foo.v -shared -o libnew.so new.o
> > cc    -c -o main.o main.c
> > cc -o new libnew.so main.o -Wl,-rpath,
> > cc -fPIC   -c -o old.o old.c
> > cc -Wl,-soname,libfoo.so -shared -o libold.so old.o
> > cc -o old libold.so main.o -Wl,-rpath,
> > ln -sf libnew.so libfoo.so
> > ./old
> > original_foo
> > ./new
> > new_foo
> > ln -sf libold.so libfoo.so
> > ./old
> > foo
> > ./new
> > ./new: libfoo.so: no version information available (required by ./new)
> > foo
> 
> Hello H.J.,
> 
> I know this sounds bizarre, but I made one change to your code: I renamed 
> the global symbol "foo" to "xyz", and now things no longer work as they 
> did for you above.  Instead, I get the behavior I described in my earlier 
> mail, as shown in the script below.  I have banged my head on this for 
> quite a while and concluded that something extremely weird is going on, or 
> that I'm being very blind.  Can you enlighten me?  (I've attached my 
> modified version of your code.)

Attachment: test_mtk.tar.gz
Description: GNU Zip compressed data