[devel] Fw: glibc 2.2.4

[Aleksey Novodvorsky]

Hi!
Обратите внимание на часть этого письма после анонса glibc, со
слов "And now for some not so nice things."
Грустно.
Rgrds, Алексей

Начало пересылаемого сообщения:

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

	ftp://sources.redhat.com/pub/glibc/releases

and (hopefully soon)

	ftp://ftp.gnu.org/pub/gnu/glibc

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:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Version 2.2.4

* 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
	i[3456]86-*-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
is unknown:

	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

  http://sources.redhat.com/ml/libc-alpha/2001-08/msg00114.html

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
specific architecture.

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

	make localedata/install-locales

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
libc-alpha на sources.redhat.com mailing list.


Responsible for this release are the usual suspects whom I want
to
thank:

	Bruno Haible
	Isamu Hasegawa
	Andreas Jaeger
	Jakub Jelinek
	Geoff Keating
	Mark Kettenis
	Kaz Kylheku
	H.J. Lu
	Roland McGrath
	Andreas Schwab


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
up forever.

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


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
work harm.


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  
`------------------------
_______________________________________________
Devel mailing list
Devel на linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel