This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: DT_NEEDED
- To: Bharadwaj Yadavalli <bharadwaj dot yadavalli at compaq dot com>
- Subject: Re: DT_NEEDED
- From: Mark Kettenis <kettenis at science dot uva dot nl>
- Date: 18 May 2001 17:39:11 +0200
- Cc: amodra at one dot net dot au, hjl at gnu dot org, binutils at sources dot redhat dot com
- References: <200105181454.KAA22587@ives.lkg.dec.com>
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