[devel] Fw: glibc 2.2.4
aen на altlinux.ru
Чт Авг 16 14:17:45 MSD 2001
Обратите внимание на часть этого письма после анонса glibc, со
слов "And now for some not so nice things."
Начало пересылаемого сообщения:
Date: 15 Aug 2001 22:09:23 -0700
From: Ulrich Drepper <drepper на redhat.com>
To: GNU libc testers <libc-alpha на sourceware.cygnus.com>, VGER gcc
list <linux-gcc на vger.kernel.org>,
libc-announce на sources.redhat.com
Subject: glibc 2.2.4
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
fixed. There are only a few new features:
* Stephen Moshier implemented cosh, expm1, log1p, acos, sinh,
asinh, atanh, j0 for the 128-bit long double format.
* Bruno Haible updated all the code handling Unicode in some form
support Unicode 3.1.
* Speed of regex for single-byte locales is back to previous
Patch by Isamu Hasegawa.
* Alpha, SPARC, and IA-64 now also using floating stacks.
* Startup time of internationalized applications greatly improved
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
severe performance problems. Patch by David Mosberger.
* The Hurd port got a lot more functionality like AIO, various
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
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
Upgrading is highly encouraged.
*BUT*: updating the C library is no trivial task and it is very
to damage one's system. Therefore, persons who do not exactly
what to do, should consider using a binary distribution instead,
it becomes available. All major Linux distributors will
base their next release on glibc 2.2.4. Don't tell us you
been warned. Another reason why not everybody should think about
compiling glibc is the disk and CPU requirements: on Intel
the full build requires about 330MB plus the space you need to
it. This number is higher on most RISC platforms. During the
compilation the compiler will need large amounts of virtual
We are talking about 100MB on Intel and 200MB on Alpha. If using
`-j' option of make these numbers grow linearly. Building the
complete library without profiling support on a 2xPIII на 550MHz
takes about 32 minutes, checking adds another 18 minutes. On not
highly tuned and slower systems the times are very much higher
possibly takes several days on very old and slow systems. The
option for make is very useful on SMP systems, the Makefiles are
for builds with high '-j' numbers (except when the compilation
in the source directory; simply create a new directory and
that one instead).
It is generally always a good idea to build in a separate
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
are necessary. The most important one is the compiler. Although
other versions might work it is recommended to get at least gcc
plus some patches as explained in
Maybe the patches are meanwhile in the gcc CVS archive and using
all that is needed. Earlier gcc versions are known to produce
incorrect code in certain situations. Even better optimized code
be generated with later development versions of the compiler.
And while we are talking about compilers: gcc 3 can *NOT* be
In case a compilation fails and the compiler is not 2.95.3 (+
get this compiler version first before reporting problems. If
make with the -n option and search for errors in the log make
distinguish between real bugs and cases where the glibc Makefiles
explicitly ignore failures.
You may need development versions of the compilation tools on
supported architectures. The requirements for MIPS are described
the FAQ. For others contact the developers working on tools for
In case you are modifying the source files which will cause
to run make sure you have autoconf 2.13 installed and *NOT*
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).
option allows one to strip out compatibility code for older
versions. This is of interest since configuring for a 2.4.x
reduces the libc size by about 1%. This is no high percentage
the code gone is in the by far most often used functions. The
compatibility code is needed because of poor design decisions of
kernel developers who constantly have to adjust the interface to
requirements. If you never expect to run kernel versions older
the one used at compile time of the library it is a good idea to
`--enable-kernel=current' to configure. But be careful since
older kernel the program won't even start and the whole system
be rendered useless (unless backup kernels are available).
The 2.2.x release should be binary compatible with the 2.1 and
releases. All correct programs should continue to run. This
*not* mean that programs compiled on a system running glibc 2.2.x
run on systems with only glibc 2.1. Compatibility is always in
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
The internal locale format has been changed (again, new in
All locale information has to be regenerated with localedef.
to install all the files. This might take a while and using the
option on SMP systems. If you are upgrading a live system with
2.1 or before you will end up with two sets of the locale data in
different places (the old data in /usr/share/locale, the new code
/usr/lib/locale). Keep the old data around until all statically
linked applications which use locales are recompiled. Then
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
the new glibc version. In a few cases programs make wrong
and the build will suddenly fail (recent example: using CLK_TCK
initializers for static or global variables which is wrong since
CLK_TCK is not guaranteed to be a constant). Make sure you
the appropriate standards before you claim to have found a bug.
Problems should all be reported using the `glibcbug' shell
*NEVER* send mail to me and preferably any other developer
I won't even read it. Mailing lists not only there to distribute
workload, they also help to archive questions and answers.
this script, fill out the information and you are set. If at the
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
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
FAQ files which come with the glibc sources. You won't even get
answer if it is obvious you haven't read these files. It is also
helpful to scan the appropriate newsgroups and mailing lists to
whether somebody else already had this problem. There is another
thing we don't want to hear about: the size. glibc is big, but
is necessary for a multi-platform Unix library.
In case the bug database is once again offline send the reports
libc-alpha на sources.redhat.com mailing list.
Responsible for this release are the usual suspects whom I want
And now for some not so nice things.
Stallman recently tried what I would call a hostile takeover of
glibc development. He tried to conspire behind my back and
the other main developers to take control so that in the end he
control and can dictate whatever pleases him. This attempt
he kept on pressuring people everywhere and it got really ugly.
the end I agreed to the creation of a so-called "steering
(SC). The SC is different from the SC in projects like gcc in
does not make decisions. On this front nothing changed. The
difference is that Stallman now has no right to complain anymore
the SC he wanted acknowledged the status quo. I hope he will now
The morale of this is that people will hopefully realize what a
control freak and raging manic Stallman is. Don't trust him. As
as something isn't in line with his view he'll stab you in the
*NEVER* voluntarily put a project you work on under the GNU
since this means in Stallman's opinion that he has the right to
decisions for the project.
The glibc situation is even more frightening if one realizes the
behind it. When I started porting glibc 1.09 to Linux (which
eventually became glibc 2.0) Stallman threatened me and tried to
me to contribute rather to the work on the Hurd. Work on Linux
be counter-productive to the Free Software course. Then came,
would be called embrace-and-extend if performed by the Evil of
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.
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
the clear motivation of commercialization. The reason: he
the provocative changes he made to the license through. In case
forgot or haven't heard, here's an excerpt:
[...] For example, permission to use the GNU C Library in
programs enables many more people to use the whole GNU
system, as well as its variant, the GNU/Linux operating system.
This $&%$& demands everything to be labeled in a way which
and he does not stop before making completely wrong statements
"its variant". I find this completely unacceptable and can
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
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
this person. Read the licenses carefully and rip out parts which
Stallman any possibility to influence your future. Phrases like
[...] GNU Lesser General Public License as published by the
Software Foundation; either version 2.1 of the License, or (at
option) any later version.
just invites him to screw you when it pleases him. Rip out the
later version" part and make your own decisions when to use a
different license since otherwise he can potentially do you or
In case you are interested why the SC could make this decision
give a bit more background. When this SC idea came up I wanted
fork glibc (out of Stallman's control) or resign from any work.
former was not welcome this it was feared to cause fragmentation.
didn't agree but if nobody would use a fork it's of no use.
also wasn't much interest in me resigning so we ended up with the
arrangement where the SC does nothing except the things I am not
myself at all: handling political issues. All technical
happens as before on the mailing list of the core developers and
reserve the right of the final decision.
The LGPL 2.1 issue was declared political and therefore in scope
the SC. I didn't feel this was reason enough to leave the
good so I tolerated the changes. Especially since I didn't
the mistake with the wording of the copyright statements which
applying later license versions before.
I cannot see this repeating, though. Despite what Stallman
maintaining a GNU project is *NOT* a privilege. It's a burden,
the bigger the project the bigger the burden. I have no interest
allow somebody else to tell me what to do and not to do if this
part of my free time. There are plenty of others interesting
do and I'll immediately walk away from glibc if I see a situation
this coming up again. I will always be able to fix my own system
if the company I work for wants it, their systems).
---------------. ,-. 1325 Chesapeake
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA
Red Hat `--' drepper at redhat.com
Devel mailing list
Devel на linux.iplabs.ru
Подробная информация о списке рассылки Devel