Re: Latest Glibc from CVS has segmentation problems.

[Nix <nix at esperi dot org dot uk>]

On 07 Mar 2004, Patrick J. LoPresti spake:
> Ulrich Drepper <drepper@redhat.com> writes:
>>     Second, you have no right to decide how I spend my time.  If you
>>     want something done there are only two ways: do it yourself, or
>>     pay somebody to do it.  Documenting the exact requirements is a
>>     futile job since it might change daily.  The matrix of
>>     architectures cross tools cross OS version is too large.
> 
> Just knowing what you use on i686-pc-linux-gnu would be a huge
> improvement.

Not really. That's the case which tends to work, because quite a lot of
people test it frequently.

Build glibc on UltraSPARC, or Alpha, or MIPS, and expect things to
go.wrong more often.

>                      Configure options, binutils version, gcc version.
> That's it.  Even if those three change daily, keeping the list updated
> would take you less time than logging in.

(In fact, that's automatable, I think, at least for ix86. Some arches
require more work before configure runs, but ix86 doesn't right now.)

> But I agree that I have no right to decide how you spend your time.

Quite so.

> If the current stable glibc does not compile easily with other current
> stable tools, that is a critical bug.  To treat it as anything less is
> to undermine the whole point of free software.

FWIW, when this sort of thing happened to current released GCCs in the
past, new releases were quickly made to resolve the problems. (The rule
is `the current released GCC must not depend on unreleased versions of
other GNU tools', and I think it's a good rule, for all that it slightly
slows adoption of new features.)

> For what good is the source code if I cannot compile it?

Reading? (Admittedly it's hard to help out with glibc if compilation is
failing for you and you can't work out why; sure, perhaps you should be
able to diagnose the problem, but it might involve deep wizardry, and
even if you can't diagnose it, it might be blocking you working on
non-wizardly parts, thus giving the wizards more time to work on the
wizardry.)

Ulrich's points are certainly well-made: glibc is about an order of
magnitude harder to keep working than any other free software in my
experience. Some of that is intrinsic (it straddles several difficult
chasms, handing the arch-dependent magic of relocation, the standards
pedantry of the userspace interface, and the latest-whizz-bang of
the changing kernel interfaces), but I find myself wondering whether
all of it necessarily is.

I expect a lot of the trouble is, as ever, a simple lack of
person-hacking-hours to fix these problems :(

-- 
RMKQLEEKVYELLSKVACLEYEVARLKKVGE
  -- ligate me, I want to live