This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: DT_NEEDED
- To: amodra at one dot net dot au
- Subject: Re: DT_NEEDED
- From: "H . J . Lu" <hjl at lucon dot org>
- Date: Fri, 18 May 2001 09:00:27 -0700
- Cc: binutils at sources dot redhat dot com
- References: <20010518174838.B30444@squeak.one.net.au>
On Fri, May 18, 2001 at 05:48:38PM +0930, amodra@one.net.au wrote:
> Hi HJ,
> 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.
>
> If a shared object name has one or more slash (/) characters anywhere in
> the name, such as /usr/lib/lib2 above or directory/file, the dynamic
> linker uses that string directly as the path name."
That brings a question. Should
# gcc -shared -o libfoo.so -L/bar -lbar
record /bar/libbar.so in DT_NEEDED? If yes, should
# gcc -shared -o libfoo.so -L../bar -lbar
record ../bar/libbar.so in DT_NEEDED? I tend to think No since -lbar
implies libbar.so without the full pathname. In that case, we just
have to make sure that we do
# gcc -shared -o libfoo.so ../bar/libbar.so
right. Any comments?
H.J.