Re: A patch for default version and archive

["H . J . Lu" <hjl at valinux dot com>]

On Mon, Nov 13, 2000 at 10:52:47PM -0800, Ulrich Drepper wrote:
> "H . J . Lu" <hjl@valinux.com> writes:
> 
> > Do you agree that foo@@ver1 will resolve both foo and foo@@ver1?
> 
> First, how can there be a reference foo@@ver1?  This is not possible
> in the versioning model except for ld.so (of course).  It is possible
> only with this unintended loop hole where you define versions to
> undefined symbols.  But this is not intended to work.  A version
> always has a DSO associated with it.  I've already explained this on
> occasion, the version information is a tuple.

That is not entirely true. I have given examples between ld.so and
libc.so, libpthread.so and libc.so, where a symbol definition from
one DSO overrides the other. They have to have the same version name
in order to work right. If you don't believe, you change change
the version name in ld.so to something else. Yes, I know there are
some symbols in libpthread.so have different version names from
libc.so. But I have provided a testcase to show the bug.

> 
> In this context, what is an undefined, versioned symbol supposed to
> be?  The DSO reference part is undefined.  The consequences of this
> are not understood.
> 
> Now, iff (note the two f) we assume for a moment this would be
> desirable, why should should it suddenly be possible to satisfy an
> explicit reference with a non-versioned symbol?  An counter-example
> can easily be constructed:
> 
> - you create a .o file with the .symver hack, referencing version ver2.
>   The corresponding .so and .a have an appropriate definition (for ver1
>   and ver2)
> 
> - you now link instead against an earlier version of the .a or DSO which
>   only has one implementation and does not use versioning, therefore
>   providing only the older (assume the ver1) implementation.
> 
> The linker would with your modifications successfully link although
> this is wrong (otherwise there wouldn't be @ver2).

It sounds like you have a testcase. But I don't think my linker will
successfully link. If you can show me such a testcase, I will withdraw
my patch.

On machine where libc.a is versioned,

# cat x.c
#include <stdio.h>

int
main ()
{
  FILE *fp = fopen ("/tmp/foo.out", "w");

  fprintf (fp, "Hellow world\n");
  fclose (fp);
  return 0;
}
# gcc -c x.c
# nm x.o
         U fclose@GLIBC_2.1
         U fopen@GLIBC_2.1
         U fprintf@GLIBC_2.0
00000000 t gcc2_compiled.
00000000 T main
# gcc x.co

On machine where libc.a is not versioned,

# gcc x.o -static
x.o: In function `main':
x.o(.text+0x11): undefined reference to `fopen@GLIBC_2.1'
x.o(.text+0x27): undefined reference to `fprintf@GLIBC_2.0'
x.o(.text+0x33): undefined reference to `fclose@GLIBC_2.1'
collect2: ld returned 1 exit status


H.J.