This is the mail archive of the mailing list for the glibc 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: [PATCH] Enable building glibc with gold.

On 01/10/2013 02:21 PM, Mike Frysinger wrote:
> On Thursday 10 January 2013 13:28:05 H.J. Lu wrote:
>> On Thu, Jan 10, 2013 at 7:11 AM, Carlos O'Donell <> 
> wrote:
>>> On 01/10/2013 12:05 AM, Roland McGrath wrote:
>>>> The changes in question allow more build environments through the
>>>> existing filter of "good enough to try building" that we enforce with
>>>> configure checks.  It's wrong to let through environments that we
>>>> aren't sure work and we have some reason to think don't.
>>> Right, and that's where we have an issue of consensus.
>>> What do we want to guarantee with our configure checks?
>>>> I already find it easy enough that I think time would be spent better
>>>> diagnosing the remaining problems with gold than frittering about
>>>> this.  But fine, make it easier as long as you do it without
>>>> regressing things like the build environment checks and without
>>>> introducing unnecessary hair.  A scary-looking maintainer-only option
>>>> to disable the build environment checks or turn them into warnings is
>>>> certainly fine and appropriate.  I don't have sources in front of me,
>>>> but perhaps --disable-sanity-checks is already that or close enough
>>>> that it's easy to change it to be that.
>>> No, after sleeping on it I realize that you're right, such a
>>> super-secret option is not what our users need.
>>> Our users need a working glibc + gold configuration.
>> -fuse-ld=gold is a well localized change.  It can be easily backported
>> to older branches.  I backported it to hjl/gold/gcc-4_7-branch.
> that's great (i'm debating adding to gentoo's 4.6/4.7 branches), but that 
> doesn't change the answer to the question "does glibc work correctly when 
> linked w/gold"

It doesn't quite. The statically linked testsuite failures indicate a real

The policy question that follows is "What do we guarantee our users
when configure completes successfully?"


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