This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


H.J. Lu wrote:
> 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.
>

I found that when I removed "-Wl,-rpath..." statements in LDFLAGS (from a
standardized build environment), the glibc build process produced an ld.so that
readelf could read.

--
Yorick


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]