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

[Ian Lance Taylor]

Robert Millan <zeratul2@wanadoo.es> writes:

> The part of _try_needed which causes the function to return FALSE in
> all the cases where it's run is:
> 
>   if ((bfd_get_file_flags (abfd) & DYNAMIC) == 0)
>     {
>       bfd_close (abfd);
>       return FALSE;
>     }
> 
> Which in runtime turns out to be:
> 
>   if ((274 & 64) == 0)
> 
> I.e: 00000001 00010010 and 00000000 1000000 which result in 0
> 
> Any hints on what could be happening?

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.

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.

Ian