[Glibc-bsd-hackers] Re: ld doesn't check for ld.so.1 in /lib

[Robert Millan]

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:

  address@hidden:~$ /lib/ld-2.3.2.so
  Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
  [...]
  address@hidden:~$ file /lib/ld-2.3.2.so
  /lib/ld-2.3.2.so: ELF 32-bit LSB shared object, [...]

And on GNU/KFreeBSD:

  address@hidden:~$ /lib/ld-2.3.so
  Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
  [...]
  address@hidden:~$ 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)