Glibc-2.3.3 tarball

Greg Schafer gschafer at zip.com.au
Sat Jan 10 03:52:04 PST 2004


Hi

Ok, here is the current status:

I'm going to place these commands into Ch 4 which have been used to create
our unofficial tarball that will hopefully be mirrored by our LFS mirror
sites that agree to it. (I'm counting on Gerard to sort out this mirroring
aspect).

  cvs -z 9 -d :pserver:anoncvs at sources.redhat.com:/cvs/glibc \
     export -d glibc-2.3.3-20031202 -D "2003-12-02 UTC" libc

  tar jcvf glibc-2.3.3-20031202.tar.bz2 glibc-2.3.3-20031202

Notice I've used "export" instead of "checkout" which means we miss out on
all the "CVS" cruft. Notice also that the chosen name indicates clearly that
this is an unofficial tarball which I think is important. But a downside to
this name is that some aesthetics may be lost e.g. the headings in the Glibc
sections will be:

"Installing Glibc-2.3.3-20031202"

which looks a little unsightly but I suppose we could always hack around it
in the LFS XML source with some entity-fu.

Notice also that "2003-12-02 UTC" is equivalent to "2003-12-02 00:00:00
UTC". There is no point in stuffing about with hours, minutes and seconds
when YMD notation works fine for our purposes here (think about it -- the
next commit after the 2.3.3 cutoff at "2003-12-01 08:29:33 UTC" was at
"2003-12-02 07:37:29 UTC").

The Glibc build commands will need to be modified slightly. Either we change
"--enable-add-ons" to "--enable-add-ons=linuxthreads" or we simply slot in a
"rm -r nptl*", which is probably easier. Also, if we want to avoid a
spurious and harmless warning about a missing autoconf, we might want to add
"--without-cvs".


IMPORTANT
=========
Of course, there is a catch to all of this and that is -- by using the new
Glibc we are bringing on the pain of the Coreutils POSIX compliance madness.
IMNSHO we have no choice but to adopt the stance that at least Debian and
RedHat have taken and that is to patch coreutils so that the old behaviour
is preserved. I know there will be folks who object to this. Fine, your
distro your rules. But for the LFS book there is really no choice. I have
thought about this long and hard and have come to the conclusion that
patching is the correct way to go for the general case. For those who want
pain, the new "reject old syntax" behaviour can still be had by setting an
environment variable, or you can just elect not to use the patch and deal
with the consequences yourself.

Here is the proposed patch:

http://www.linuxfromscratch.org/patches/downloads/coreutils/coreutils-5.0-posixver-1.patch

There are still plenty of ongoing heated discussions happening around the
place where diehard toolchain developers think the coreutils maintainers
have done the wrong thing with this whole affair. I tend to agree with them.

In the meanwhile, if there are keen testing folks out there who want to test
all of the above before it goes into the book, please feel free and don't
forget to report your experiences.

Essentially, I'd like to have our unofficial tarball available for download
from the mirrors before putting all of the above into the book.

Greg



More information about the lfs-dev mailing list