Re: [Ulrich Drepper <drepper@cygnus.com>] glibc 2.1.1

[Andreas Jaeger <aj@arthur.rhein-neckar.de>]

>>>>> Clayton Weaver writes:

 > Is he for real on this "use the binary distribution" noise? So
 > did he compile it for 386, 486, 586, or 686? What were the
 > gcc compile/link command lines, exactly?

 > Without belittling Ulrich's enormous contribution, that's a ridiculous
 > suggestion, imho. "If you can't compile it, don't use it." Words to
 > live by.
Allow me to answer in more detail and CC this again to glibc-linux
since I think this might be of more general interest.  I do think
you're reading a bit too much into Ulrich's announcement.

We, the glibc developers, release pre releases and ask others to test
those on their systems.  We're also regulary compiling glibc on our
own machines [1] and it works for us and we didn't get any bad feedback
for the prereleases.  But there are a number of varying factors, like:
- kernel version
- compiler version
- tools versions (make, bash, texinfo, sed, ...)
- binutils versions
- compiler/linker tools

We can't test all combinations.  If you like to help testing some of
these combinations, please subscribe to
libc-alpha@sourceware.cygnus.com (for details about the subscription
mechanism check <http://sourceware.cygnus.com/glibc>) and help us.

Updating the kernel is normally easy since `make zlilo' installs a
backup kernel and you can start again with the old kernel.  But what
happens if your libc is not working?  There's no easy way - if you
didn't care before - to repair your system.  Using a distribution
should be a safe upgrade.  You can guard yourself against a broken
glibc installation in different ways, e.g. keeping a copy of /lib
around (see the FAQ for details), having a statically linked shell
like sash to boot with (init=/bin/sash on the kernel command line)
etc.  But all of this requires at least a basic understanding of the
internals of your system.  And if you don't have it, you should use a
distribution and not try to compile it yourself.

Besides upgrading glibc, you need also to upgrade some libraries - and 
if you've got a slow machine as I have - you need a day for just
compiling and testing everything that needs upgrading.

With glibc 2.1* you need recent binutils and compiler to compile glibc
- and the installation of those is a wee bit involved.

Let's look again at Ulrich's announcement:
> - do you really have to?  It's not easy and the tools must really work.
>   We don't have the time to lead people through the process.

I agree with his statement and would emphasize: If everything works,
upgrading shouldn't be a problem --- but if anything doesn't work, it
gets complicated and we don't have the time to help everybody --- and
it's sometimes impossible to help via email by just guessing what
might be wrong.

For compiliation of glibc I advise to follow the INSTALL file and use
a separate build directory and don't specifiy any extra
compiler/linker flags, e.g.[2]:
mkdir build-directory
cd build-directory
<path-to-glibc-sources>/configure --prefix=/usr --enable-add-ons
make
make check
make install (or: make install_root=/tmp install and use tar/cpio for
proper installation)

Feel free to install it - and if you've got problems and report them
with the glibcbug script, we *try* to help.  But we don't advise
anybody that just installed yesterday the first SuSE, RedHat, Debian or
whatever distribution to upgrade to glibc 2.1.1 by hand.

Btw. Ulrich didn't make binary packages himself, but I know that some
distributors already have binary packages of prereleases of glibc
2.1.1 and I'm convinced they're going to use 2.1.1 final as basis
soon.

Andreas

Footnotes: 
[1]  I'm running an i486, others use i586, i686, alpha, Sparc, ARM, ...
[2]  That's the way I compile glibc regulary.

-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de