Re: Binutils linker bug?

[Geoff Keating <geoffk at ozemail dot com dot au>]

> Date: 8 Nov 1999 22:30:04 -0500
> From: Ian Lance Taylor <ian@zembu.com>

> Are you suggesting that the program linker should reject an attempt to
> use a symbol from a shared library which is only included indirectly?
> That would break existing systems.  For example, on Solaris, the
> shared X library includes other libraries.  If we rejected references
> to shared libraries included indirectly, people would no longer be
> able to simply link against -lX11.  This would also be incompatible
> with the Solaris linker.

I am suggesting exactly this.  I just checked, and the solaris 2.5.1
linker does what I am suggesting:

geoffk@sloth 2:38pm>cat > t.c
#include <stdio.h>
extern int XSolarisOvlGetPaintType();
int main(void)
{ printf("XSolarisOvlGetPaintType is at %p\n", XSolarisOvlGetPaintType);  
  return 0;
}

geoffk@sloth 2:39pm>gcc t.c -o t -L/usr/openwin/lib -lX11
Undefined                       first referenced
 symbol                             in file
XSolarisOvlGetPaintType             /tmp/ccTuJchj.o  (symbol belongs to implicit dependency /usr/openwin/lib/libXext.so.0)
ld: fatal: Symbol referencing errors. No output written to t
collect2: ld returned 1 exit status

but if you instead write

geoffk@sloth 2:39pm>gcc t.c -o t -L/usr/openwin/lib -lX11 -lXext

it works.  They even print the library name that you need to add to
the link line, which we should try to do too :-).

Here, libX11 has:

geoffk@sloth 2:40pm>objdump -p /usr/openwin/lib/libX11.so.4 | grep libXext
  NEEDED      libXext.so.0

and libXext has:

geoffk@sloth 2:41pm>objdump -T /usr/openwin/lib/libXext.so.0 | grep XSolarisOvlGetPaintType
0000a978 g    DF .text  000000ec XSolarisOvlGetPaintType

>    >    However, if the program references `write' instead of `pthread_self'
>    >    things are a little different.  I think the desired behaviour here is
>    >    to record that the program needs the appropriate version of `write'
>    >    from libc.so instead of libpthread.so (which gets sucked in via an other
>    >    library we link against).  Is this failing because `write' is weak in
>    >    libc.so and isn't in libpthread.so?  Or would it be a problem anyhow,
>    >    that is, even when `write' is weak in libpthread.so too?
...

I think this is superceded by the above comment.  If you're not
allowing indirect dynamic symbol referencing, the linker should assume
that the symbol that applies is the one in libc if that is the one it
can see.

-- 
Geoffrey Keating <geoffk@cygnus.com>