This is the mail archive of the libc-alpha@sourceware.org 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.


> It is not a completely obvious conclusion and I didn't want to assume
> what rationale you had for recommending against it. I respect your
> opinion, but if you don't write it out I can't know what it is :-)

Oh, that's extremely simple: my opinion matches the objectively
optimal answer in every case.  Therefore, you just have to become
entirely correct and then you'll know what I wanted.  (It is a strange
property of the universe that the objectively optimal truth about
things can change suddenly when I get more information or have an
epiphany in the shower.)

> What I don't quite understand is why you are espousing what appears
> to be a rather strict requirement for the addition of a new build
> configuration. I don't know that it's healthy for the community to
> adopt a "don't include it until it's perfect" policy.

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.

All the changes I made many months ago to enable using gold were
included then though using gold remained imperfect (and entirely
broken due to gold bugs, at the time).  Any more changes along the
same lines could go in now too, if they are good changes.

What shouldn't go in is relaxation of the build requirements to admit
things that don't work.

> At present it's cumbersome to test building glibc with gold, but
> with either your patch, or mine (I'm not picky) *already* checked
> in we could make it as easy a symlink flip (e.g. FC17 `alternatives')
> and a rebuild with no need to switch branches / rebase or apply a
> patch.

I never found switching branches cumbersome.  That's why we use git.
Whenever I start up looking at this again, I rebase
roland/gold-vs-libc and it takes about ten seconds.

(And you're welcome for hacking the Fedora binutils packaging to
support alternatives for ld, which I did about the same time I did all
the libc changes that make building with gold possible.  A solution
that's even better in many ways has recently gone into trunk
GCC/binutils, thanks to HJ: CC='gcc -fuse-gold'.)

> I think we should make it easier to build and test with gold.

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.


Thanks,
Roland


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