This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ld doesn't check for ld.so.1 in /lib
- From: Robert Millan <zeratul2 at wanadoo dot es>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: bug-binutils at gnu dot org, binutils at sources dot redhat dot com,glibc-bsd-hackers at nongnu dot org,glibc-bsd-devel at lists dot alioth dot debian dot org
- Date: Fri, 29 Aug 2003 20:00:53 +0000
- Subject: Re: ld doesn't check for ld.so.1 in /lib
- Organisation: free as in freedom
- References: <20030730013508.GA24581@aragorn> <20030730025859.GA24781@aragorn> <m3ptjsd7hu.fsf@gossamer.airs.com> <20030804032508.GA647@aragorn> <m3smoii4lg.fsf@gossamer.airs.com> <20030829145316.GA20557@aragorn> <m38ypcpepp.fsf@gossamer.airs.com>
On Fri, Aug 29, 2003 at 10:15:46AM -0700, Ian Lance Taylor wrote:
>
> This makes it appear that you have a DT_NEEDED entry for ld.so.1, but
> that ld.so.1 is an executable rather than a shared object. Certainly
> the name suggests a shared object.
Great! You guessed right :)
ld-2.3.so is part of Glibc. On my GNU/Linux systems, it is a shared object,
but it may work as an executable at the same time:
rmh@aragorn:~$ /lib/ld-2.3.2.so
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
[...]
rmh@aragorn:~$ file /lib/ld-2.3.2.so
/lib/ld-2.3.2.so: ELF 32-bit LSB shared object, [...]
And on GNU/KFreeBSD:
rmh@bilbo:~$ /lib/ld-2.3.so
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
[...]
rmh@bilbo:~$ file /lib/ld-2.3.so
/lib/ld-2.3.so: ELF 32-bit LSB executable, [...]
My guess is that Glibc is on fault here for linking ld-2.3.so without having
"-shared" in CFLAGS.
Unless you think otherwise, I'll investigate the problem in Glibc and
provide a definitive patch for GNU/KFreeBSD support in binutils.
Thanks a lot for your help!
> The question then is why you have a DT_NEEDED entry for an executable.
> I can't think of any circumstance in which that would occur.
>
> Looking at my ix86 GNU/Linux systems, I see that ld-linux.so.2 is a
> shared object, but that ld.so.1.9.5 is an executable. But I don't
> have any DT_NEEDED entries for ld.so.1.9.5.
>
> Is it possible that there is another ld.so.1 somewhere, one which
> really is a shared library?
>
> Your original messages says that the DT_NEEDED entry occurs in
> /lib/libc.so.1. How was that built?
>
> > It gives me the impression that bfd_get_file_flags checks wether the dynamic
> > flag is enabled in the object and returns it in the 7th bit, as defined by
> > the DYNAMIC macro. Is that it? If it is, where should I blame it on that
> > ld.so.1 doesn't have the dynamic flag enabled?
>
> The DYNAMIC flag is set if the ELF file has type ET_DYN. But if
> ld.so.1 really is an executable, then it is correct for it to have
> type ET_EXEC rather than ET_DYN.
--
Robert Millan
"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."
-- J.R.R.T, Ainulindale (Silmarillion)