This is the mail archive of the libc-alpha@sources.redhat.com 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: Latest Glibc from CVS has segmentation problems.


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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


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)

iD8DBQFAS3dk2ijCOnn/RHQRAkDAAKDIuOXgiLCfnslLLXFn+7DnAfXFwQCgwUu7
ZPEtXf1MgA7eBjzVKxxczuI=
=Wo+B
-----END PGP SIGNATURE-----


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