Re: Latest Glibc from CVS has segmentation problems.

["Patrick J. LoPresti" <patl at users dot sourceforge dot net>]

Ulrich Drepper <drepper@redhat.com> writes:

> I'm going to send this one reply and one reply only.  I anyone wants to
> start a flame war on it, you better take it somewhere else.  This is all
> highly off-topic.  I mean it.  Create your lists or blogs dedicated to
> hating me somewhere else and enjoy.

This will be my last message as well, unless Alfred says something
else particularly stupid.

> 3.  Ergo, the only safe way to install a new glibc version is to install
>     in some other place (chroot or whatever), package it up, and then
>     use a special packaging tool like rpm to put the new binaries in
>     place.  That's the only sane way.

If you cared about letting end-users install glibc, you could design
an installation procedure which "just worked".  Or you could indicate
some willingness to accept patches to implement such a procedure.

But you don't, so you won't.

> 6.  I constantly refer to the distribution makers since I have no time
>     and absolutely no interest in helping every Joe Sixpack to install
>     glibc.

I wish all free software maintainers had this attitude.  I mean, think
how much better all the software would be if the maintainers didn't
waste their time worrying about non-experts compiling their code!

>     glibc stresses all tools to the limits and therefore
>     requires very carefully selected versions.  And the requirements can
>     change daily.  The work a non-distribution user has to do to get
>     glibc going is enormous since not only will you have to follow the
>     glibc development, you also have to keep an eye on gcc and binutils
>     patches.  And no, just using the latest gcc doesn't work either
>     since we don't have time to follow the latest version with all the
>     associated problems.

The Linux kernel somehow manages to compile with anything from gcc
2.95 through gcc 3.3.3.  Just coincidence, I guess.  I mean, surely
the Linux developers would not be so stupid as to waste their time
WORKING on keeping it that way.

> 8.  Cries like "then at least document what is needed" fall into the
>     same category.  First, it is something which is not necessary to get
>     glibc going for 95% of all people (those using a distribution).

You seem to think of those 95% as your "customers".  But this is free
software.  Your true "customers" are the people who want to read and
modify your code.  Those are not just distribution makers; they are
people with applications you do not and cannot anticipate.

>     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.  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.

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

> 10. If you've done that and you feel like documenting it, write it up,
>     post it to some website, and send a reference to the list.  You'll
>     see how much time it takes to keep this up-to-date and answering all
>     questions.

You are suggesting I create something ("glibc for end-users") which
the glibc maintainer not only does not support, but would actively
like to see fail?  Yeah, that sounds like fun.

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.

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

Pretty much everything I have to say is summarized in that one
question.

 - Pat