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.21.51.0.2 fails to build glibc


On Wed, Jan 12, 2011 at 9:01 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Wednesday, January 12, 2011 08:52:37 H.J. Lu wrote:
>> On Tue, Jan 11, 2011 at 11:09 PM, Mike Frysinger wrote:
>> > On Wednesday, January 12, 2011 01:46:42 H.J. Lu wrote:
>> >> On Tue, Jan 11, 2011 at 10:43 PM, Ian Lance Taylor wrote:
>> >> > "H.J. Lu" writes:
>> >> >>> It's quite likely that I misunderstand. ?It sounds like you are
>> >> >>> saying that it's OK for GNU ld to segfault when building an older
>> >> >>> version of Linker doesn't segfault.
>> >> >>> glibc. ?The linker isn't like the compiler, where we tighten
>> >> >>> restrictions on the input language. ?The linker should accept old
>> >> >>> object files. ?And of course it should never segfault. ?But if I
>> >> >>> misunderstand, then I apologize for raising the issue.
>> >> >>
>> >> >> The problem is the linker generates bad libc.so with unfixed glibc.
>> >> >> The fix is trivial and leads to slightly better libc.so as extra
>> >> >> bonus.
>> >> >
>> >> > Thanks for the correction, but that's sort of worse.
>> >>
>> >> It happens at build-time and build won't finish.
>> >
>> > assuming native build. ?a cross-build wont have a clue.
>>
>> Well, you have to test your build.
>
> yes, and when you test it, all you know is it segfaults. ?there is no "it
> doesnt finish building" issue, and for the majority of people out there, they
> wont have any idea. ?they'll just start googling for "glibc segfault" or try
> random versions of the toolchain pieces until they get a component that works.
> but i guess you really cant detect this change since it is done at the linker
> script level. ?code that used to compile & link & run but now compiles & links
> & silently segfaults sucks the most for end users. ?at least with a link time
> warning they have a fighting chance of figuring things out.

If you are building glibc yourself, you should be on the glibc mailing list
and keep tracks of what is going on.


-- 
H.J.


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