Re: DT_NEEDED

[Mark Kettenis <kettenis at science dot uva dot nl>]

Bharadwaj Yadavalli <sby@ives.lkg.dec.com> writes:

> On Fri, 18 May 2001 17:48:38 +0930 amodra@one.net.au wrote:
> 
> > I suspect some of your recent changes to elflink.h are in 
> > violation of the ELF spec.
> > http://www.sco.com/developer/devspecs/gabi41.pdf says:
> >
> >
> > "Names in the dependency list are copies either of the DT_SONAME strings
> > or the path names of the shared objects used to build the object file.
> > For example, if the link editor builds an executable file using one
> > shared object with a DT_SONAME entry of lib1 and another shared
> > object library with the path name /usr/lib/lib2, the executable file
> > will contain lib1 and /usr/lib/lib2 in its dependency list.
> 
> Having been the "bug" reporter I feel obliged to speak up.
> 
> On reading the above referenced spec. closely, I am inclined to 
> agree with Alan Modra. Also it seems to me that the linker, prior
> to HJ's fix has been behaving in accordance with the spec. In 
> other words, it was adding the full path names of .so files to 
> the dependency list of the linked output since they *did not*
> have DT_SONAME strings.

The Solaris linker also records the full path name.  Therefore I think
HJ should revert his patches.  Why did he check them in without
discussing them in the first place?

> DT_NEEDED entries of libfoo.so? I tried using both the following
> commands:
> 
> gcc -shared -o libfoo.so foo.c /full/path/to/liba.so  /full/path/to/libb.so
> 
> as well as 
> 
> gcc -L/full/path/to -shared -o libfoo.so foo.c -la  -lb
> 
> but got the full path of liba.so and libb.so listed in the dependency
> list of libfoo.so.

Are you sure that the second example does indeed encode the full
pathname?  I just did something similar with GNU ld (a recent CVS version) on
Solaris and it seems to work for me, that is, the full pathname isn't
encoded in the DT_NEEDED entry.

Mark