This is the mail archive of the
mailing list for the GNU libc project.
- To: GNU libc testers <libc-alpha at sourceware dot cygnus dot com>, VGER gcc list <linux-gcc at vger dot kernel dot org>, libc-announce at sources dot redhat dot com
- Subject: glibc 2.2.4
- From: Ulrich Drepper <drepper at redhat dot com>
- Date: 15 Aug 2001 22:09:23 -0700
- Reply-To: drepper at cygnus dot com (Ulrich Drepper)
Release 2.2.4 of the GNU C library is now available at
and (hopefully soon)
and all the mirror sites around the globe.
The new files are
glibc-2.2.4.tar.bz2 (also .gz)
glibc-linuxthreads-2.2.4.tar.bz2 (also .gz)
glibc-2.2.3-2.2.4.diff.bz2 (also .gz)
and for those following the test releases
glibc-2.2.4pre3-2.2.4.diff.bz2 (also .gz)
The patch from 2.2.3 is pretty big but a lot are non-code-related
changes. The code which did changed mainly got better due to bugs
fixed. There are only a few new features:
* Stephen Moshier implemented cosh, expm1, log1p, acos, sinh, tanh,
asinh, atanh, j0 for the 128-bit long double format.
* Bruno Haible updated all the code handling Unicode in some form to
support Unicode 3.1.
* Speed of regex for single-byte locales is back to previous levels.
Patch by Isamu Hasegawa.
* Alpha, SPARC, and IA-64 now also using floating stacks.
* Startup time of internationalized applications greatly improved through
iconv cache. Use iconvconfig to generate the cache file.
Contributed by Ulrich Drepper.
* The IA-64 specific part of ld.so was rewritten to eliminate some pretty
severe performance problems. Patch by David Mosberger.
* The Hurd port got a lot more functionality like AIO, various stdio
extensions, etc. Mainly done by Roland McGrath.
* mtrace can now lookup symbols in shared libraries.
This release of the library runs on the following targets:
*-*-gnu GNU Hurd
i86-*-linux-gnu Linux-2.x on Intel
m68k-*-linux-gnu Linux-2.x on Motorola 680x0
alpha-*-linux-gnu Linux-2.x on DEC Alpha
powerpc-*-linux-gnu Linux-2.x on PowerPC systems
sparc-*-linux-gnu Linux-2.x on SPARC
sparc64-*-linux-gnu Linux-2.x on UltraSPARC
s390-*-linux-gnu Linux-2.x on S390
sh*-*-linux-gnu Linux-2.x on SH
ia64-*-linux-gnu Linux-2.x on IA-64
Work is in progress to make the following targets work (again):
arm-*-linux-gnu Linux-2.x on ARM
hppa*-*-linux-gnu Linux-2.x on HP/PA
mips*-*-linux-gnu Linux-2.x on MIPS
Previous releases worked on the following targets, the current status
arm-*-none ARM standalone systems
arm-*-linuxaout Linux-2.x on ARM using a.out (obsolete?!)
We believe that this release is very stable, more so than any before.
Upgrading is highly encouraged.
*BUT*: updating the C library is no trivial task and it is very easy
to damage one's system. Therefore, persons who do not exactly know
what to do, should consider using a binary distribution instead, when
it becomes available. All major Linux distributors will hopefully
base their next release on glibc 2.2.4. Don't tell us you haven't
been warned. Another reason why not everybody should think about
compiling glibc is the disk and CPU requirements: on Intel platforms
the full build requires about 330MB plus the space you need to install
it. This number is higher on most RISC platforms. During the
compilation the compiler will need large amounts of virtual memory.
We are talking about 100MB on Intel and 200MB on Alpha. If using the
`-j' option of make these numbers grow linearly. Building the
complete library without profiling support on a 2xPIII@550MHz system
takes about 32 minutes, checking adds another 18 minutes. On not
highly tuned and slower systems the times are very much higher and it
possibly takes several days on very old and slow systems. The '-j'
option for make is very useful on SMP systems, the Makefiles are save
for builds with high '-j' numbers (except when the compilation happens
in the source directory; simply create a new directory and compile in
that one instead).
It is generally always a good idea to build in a separate directory
and simply configure using
/path/to/glibc-2.2.4/configure ...options for configure...
In case you decide to compile glibc yourself you need to read the
files INSTALL and FAQ. It will explain among other things which tools
are necessary. The most important one is the compiler. Although
other versions might work it is recommended to get at least gcc 2.95.3
plus some patches as explained in
Maybe the patches are meanwhile in the gcc CVS archive and using it is
all that is needed. Earlier gcc versions are known to produce
incorrect code in certain situations. Even better optimized code can
be generated with later development versions of the compiler.
And while we are talking about compilers: gcc 3 can *NOT* be used.
In case a compilation fails and the compiler is not 2.95.3 (+ patch)
get this compiler version first before reporting problems. If you run
make with the -n option and search for errors in the log make sure you
distinguish between real bugs and cases where the glibc Makefiles
explicitly ignore failures.
You may need development versions of the compilation tools on recently
supported architectures. The requirements for MIPS are described in
the FAQ. For others contact the developers working on tools for the
In case you are modifying the source files which will cause autoconf
to run make sure you have autoconf 2.13 installed and *NOT* version
2.50 and up. These versions will not work.
One Linux systems the configure script has a new option
`--enable-kernel' (find the documentation in the INSTALL file). This
option allows one to strip out compatibility code for older kernel
versions. This is of interest since configuring for a 2.4.x kernel
reduces the libc size by about 1%. This is no high percentage but all
the code gone is in the by far most often used functions. The
compatibility code is needed because of poor design decisions of the
kernel developers who constantly have to adjust the interface to new
requirements. If you never expect to run kernel versions older than
the one used at compile time of the library it is a good idea to pass
`--enable-kernel=current' to configure. But be careful since with an
older kernel the program won't even start and the whole system might
be rendered useless (unless backup kernels are available).
The 2.2.x release should be binary compatible with the 2.1 and earlier
releases. All correct programs should continue to run. This does
*not* mean that programs compiled on a system running glibc 2.2.x will
run on systems with only glibc 2.1. Compatibility is always in one
direction. Systems with glibc 2.1 will not even attempt to run
binaries generated with glibc 2.2.x so there is not much to worry about.
The internal locale format has been changed (again, new in 2.2.4).
All locale information has to be regenerated with localedef. Simply run
to install all the files. This might take a while and using the -j
option on SMP systems. If you are upgrading a live system with glibc
2.1 or before you will end up with two sets of the locale data in two
different places (the old data in /usr/share/locale, the new code in
/usr/lib/locale). Keep the old data around until all statically
linked applications which use locales are recompiled. Then remove the
files LC_CTYPE, LC_COLLATE, LC_NUMERIC, LC_MONETARY, LC_TIME, and
SYS_LC_MESSAGES in all subdirectories below /usr/share/locale.
There are normally no problems to be expected when compiling code with
the new glibc version. In a few cases programs make wrong assumptions
and the build will suddenly fail (recent example: using CLK_TCK in
initializers for static or global variables which is wrong since is
CLK_TCK is not guaranteed to be a constant). Make sure you review
the appropriate standards before you claim to have found a bug.
Problems should all be reported using the `glibcbug' shell script.
*NEVER* send mail to me and preferably any other developer directly;
I won't even read it. Mailing lists not only there to distribute the
workload, they also help to archive questions and answers. Simply run
this script, fill out the information and you are set. If at the time
you start the script it complains like this
/usr/bin/glibcbug: emacs: command not found
set one of the environment variables EDITOR and VISUAL (this should
happen on every system automatically):
env EDITOR=vi glibcbug
Do this also if you don't want to edit the bug report in Emacs (I
cannot imagine why not but...)
Before sending a bug report make sure you have read the BUGS and the
FAQ files which come with the glibc sources. You won't even get an
answer if it is obvious you haven't read these files. It is also
helpful to scan the appropriate newsgroups and mailing lists to see
whether somebody else already had this problem. There is another
thing we don't want to hear about: the size. glibc is big, but this
is necessary for a multi-platform Unix library.
In case the bug database is once again offline send the reports to the
email@example.com mailing list.
Responsible for this release are the usual suspects whom I want to
And now for some not so nice things.
Stallman recently tried what I would call a hostile takeover of the
glibc development. He tried to conspire behind my back and persuade
the other main developers to take control so that in the end he is in
control and can dictate whatever pleases him. This attempt failed but
he kept on pressuring people everywhere and it got really ugly. In
the end I agreed to the creation of a so-called "steering committee"
(SC). The SC is different from the SC in projects like gcc in that it
does not make decisions. On this front nothing changed. The only
difference is that Stallman now has no right to complain anymore since
the SC he wanted acknowledged the status quo. I hope he will now shut
The morale of this is that people will hopefully realize what a
control freak and raging manic Stallman is. Don't trust him. As soon
as something isn't in line with his view he'll stab you in the back.
*NEVER* voluntarily put a project you work on under the GNU umbrella
since this means in Stallman's opinion that he has the right to make
decisions for the project.
The glibc situation is even more frightening if one realizes the story
behind it. When I started porting glibc 1.09 to Linux (which
eventually became glibc 2.0) Stallman threatened me and tried to force
me to contribute rather to the work on the Hurd. Work on Linux would
be counter-productive to the Free Software course. Then came, what
would be called embrace-and-extend if performed by the Evil of the
North-West, and his claim for everything which lead to Linux's
Which brings us to the second point. One change the SC forced to
happen against my will was to use LGPL 2.1 instead of LGPL 2. The
argument was that the poor lawyers cannot see that LGPL 2 is
sufficient. Guess who were the driving forces behind this.
The most remarkable thing is that Stallman was all for this despite
the clear motivation of commercialization. The reason: he finally got
the provocative changes he made to the license through. In case you
forgot or haven't heard, here's an excerpt:
[...] For example, permission to use the GNU C Library in non-free
programs enables many more people to use the whole GNU operating
system, as well as its variant, the GNU/Linux operating system.
This $&%$& demands everything to be labeled in a way which credits him
and he does not stop before making completely wrong statements like
"its variant". I find this completely unacceptable and can assure
everybody that I consider none of the code I contributed to glibc
(which is quite a lot) to be as part of the GNU project and so a major
part of what Stallman claims credit for is simply going away.
This part has a morale, too, and it is almost the same: don't trust
this person. Read the licenses carefully and rip out parts which give
Stallman any possibility to influence your future. Phrases like
[...] GNU Lesser General Public License as published by the Free
Software Foundation; either version 2.1 of the License, or (at your
option) any later version.
just invites him to screw you when it pleases him. Rip out the "any
later version" part and make your own decisions when to use a
different license since otherwise he can potentially do you or your
In case you are interested why the SC could make this decision I'll
give a bit more background. When this SC idea came up I wanted to
fork glibc (out of Stallman's control) or resign from any work. The
former was not welcome this it was feared to cause fragmentation. I
didn't agree but if nobody would use a fork it's of no use. There
also wasn't much interest in me resigning so we ended up with the SC
arrangement where the SC does nothing except the things I am not doing
myself at all: handling political issues. All technical discussions
happens as before on the mailing list of the core developers and I
reserve the right of the final decision.
The LGPL 2.1 issue was declared political and therefore in scope of
the SC. I didn't feel this was reason enough to leave the project for
good so I tolerated the changes. Especially since I didn't realize
the mistake with the wording of the copyright statements which allow
applying later license versions before.
I cannot see this repeating, though. Despite what Stallman believes,
maintaining a GNU project is *NOT* a privilege. It's a burden, and
the bigger the project the bigger the burden. I have no interest to
allow somebody else to tell me what to do and not to do if this is
part of my free time. There are plenty of others interesting things to
do and I'll immediately walk away from glibc if I see a situation like
this coming up again. I will always be able to fix my own system (and
if the company I work for wants it, their systems).
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------