binutils-2.19.1 and freshly-built ld.so from glibc 2.9

[H.J. Lu]

On Tue, Mar 3, 2009 at 8:16 AM, Poor Yorick
<org.sourceware.binutils@pooryorick.com> wrote:
> - Show quoted text -
> H.J. Lu wrote:
>> On Tue, Mar 3, 2009 at 7:05 AM, Poor Yorick
>> <org.sourceware.binutils@pooryorick.com> wrote:
>>> H.J. Lu wrote:
>>>> On Tue, Mar 3, 2009 at 4:56 AM, Poor Yorick
>>>> <org.sourceware.binutils@pooryorick.com> wrote:
>>>>> Hi,
>>>>>
>>>>> The following problem occurs with both binutils-2.19.1 and 2.18.  I
>>>>> invoke "readelf -a ld.so" where ld.so was just compiled from glibc-2.9
>>>>> source, and get an infinite loop of error messages similar to:
>>>>>
>>>>>    readelf: Error: Unable to read in 0x10 bytes of version need aux (3)
>>>>>    readelf: Error: Unable to seek to 0x87000161 for version need aux
>>>>> (3)
>>>>>
>>>>> any suggestions?
>>>>>
>>>> Which platform are you using?
>>>>
>>> Linux 2.4.21-50.ELhugemem, RHEL3, self-compiled, toolchain.
>>>  /usr/bin/readelf
>>> (gnu readelf 2.14.90.0.4) has no problem reading the new ld.so.  the new
>>> binutils readelf has no problem reading any of the other hundreds of
>>> shared
>>> objects I've compiled.  /lib/libc.so.6 is version 3.2.3.
>>>
>>
>> I assume that it is Linux/ia32.
>>
>>
>
> Yes.  In the meantime, I've found that it's the same story on another
> machin:
> x86_64, 2.6.9-55.ELlargesmp, RHEL4.  I compile binutils-2.19.1, then attempt
> to
> compile glibc-2.9.  Same infinite loop.  However, on this machine, the stock
> /usr/bin/readelf, version 2.15.92.0.2, also can not read the fresh ld.so,
> going
> into the same infinite (?) loop.
>

I have no problems with "readelf -a ld.so from the current binutils in CVS
on Fedora/10 ia32 with today's glibc in CVS.

-- 
H.J.