This is the mail archive of the
mailing list for the glibc project.
Re: Latest Glibc from CVS has segmentation problems.
-----BEGIN PGP SIGNED MESSAGE-----
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.
1. The danger of installing over a life system is **NOT** from using
the CVS code. If you think that, it's alone reason enough that
you don't try it yourself.
2. The connection between the individual parts of the glibc DSOs is
very special. The libc.so DSO uses private interfaces in ld.so
and vice versa. Now imagine what happens if, on a life system
with dynamically linked applications, the libc.so replaces the
old one with a different internal ABI and then later ld.so is
supposed to follow (or the other way around). libpthread.so,
libm.so, and librt.so fall into the same category.
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.
4. Arguing "but it worked last week" means instant disqualification
since it means somebody has no clue about the issues involved.
This somebody should first learn about the issues before starting
again to screw with the system.
5. Encouraging people to compile their own binaries has another very
serious problem: it might create a different ABI. If you don't
know _exactly_ what you are doing this is a very likely outcome.
The results of that are catastrophic and not only for the one
person her/himself. If this person distributes binaries they
might not work elsewhere and cause confusion at best.
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. 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. Doing all the prerequisite work is a full
time job by itself. Ask Jakub.
7. If somebody still insists on doing it all by her/himself and
constantly whines about the problems on the list and expects one
of the few maintainers to care: you are totally, utterly wrong.
Nobody owes you *anything*. If you get help this is a voluntary
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).
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.
9. If somebody is still not deterred from DYI, then at least start from
a reasonable point. Get a working recipe from a distribution
and do just as they do. I do not say that process is perfect, but
at least there are no fatal flaws in it. Then modify the process to
your own liking but only after giving all the implications of every
change a thorough investigation. You need, at the very least, know
how each part of the package is connected to anything. Like ABI
dependencies between libc and ld.so.
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. I regard my time as far too precious to do this and a
disservice to almost all users since every second I spent answering
emails about installation issues or writing detailed docs about how
to do it is time I cannot spend on fixing bugs, reviewing patches,
or develop improvements. Suggesting that this isn't the case is
the tell-tale sign of an egoistical moron who doesn't understand
a bit about the free software development process and the volunteer
work involved (well, and economics and the overall limitation of
So, if you insist on pestering me or anybody else doing real work on the
code because we don't jump to serve the king or queen which is you all I
can only say is: GO AWAY.
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
-----END PGP SIGNATURE-----