[devel] [drepper на redhat.com: glibc 2.3]
Dmitry V. Levin
=?iso-8859-1?q?ldv_=CE=C1_altlinux=2Eorg?=
Чт Окт 3 14:50:27 MSD 2002
FYI
----- Forwarded message from Ulrich Drepper <drepper на redhat.com> -----
Date: Thu, 03 Oct 2002 03:09:57 -0700
From: Ulrich Drepper <drepper на redhat.com>
To: libc-alpha на sources.redhat.com, linux-gcc на vger.kernel.org
Subject: glibc 2.3
Release 2.3 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.3.tar.bz2
glibc-linuxthreads-2.3.tar.bz2
glibc-2.2.5-2.3.diff.bz2
and for those following the test releases
glibc-2.2.94-2.3.diff.bz2
This release introduces a number of new features but not too many.
glibc 2.2 was already mostly complete. Instead this release focuses
on making functionality compliant with standards and on performance
optimizations. The user visible changes include:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Version 2.3
* Masahide Washizawa contributed iconv modules for IBM1163 and IBM1164
charsets.
* iconv (the program and the interface) now accepts empty names (excluding
options like //TRANSLIT) to mean "use charset of current locale".
* localedef can now transliterate characters in strings which are not in
the provided charmap. The information from the input locale is used.
* Prelinking support was added for ELF targets. This requires additional
tools and recent versions of the GNU binutils. Contributed by Jakub
Jelinek.
* Read-only stdio streams now use mmap to speed up operation by eliminating
copying and buffer underflows. To use add 'm' to the mode string of
the fopen/fdopen/freopen call. Implemented by Ulrich Drepper.
* The malloc functions were completely rewritten by Wolfram Gloger based
on Doug Lea's malloc-2.7.0.c.
* Isamu Hasegawa contributed a completely new and POSIX-conformant
implementation of regex.
* Bruno Haible upgraded the iconv and locale implementation to support
Unicode 3.2.
* Contents of the LC_* and LANG environment variables in the CEN style are
not recognized anymore. It never was used. Change by Ulrich Drepper.
* The runtime (ld.so, libc, libpthread for Linux) now can handle the ELF
thread-local storage (TLS) ABI on some platforms.
Changes by Ulrich Drepper. SH support by Kaz Kojima.
* Bruno Haible contributed iconv converters for ISO-2022-JP-3, SHIFT
JIS-X0213,
EUC-JISX0213, and TISCII.
* New header <ifaddrs.h> with functions `getifaddrs' and `freeifaddrs':
BSD-compatible interface for getting all network interface addresses.
Implementation for IPv4 by Roland McGrath.
* Loading of locale data is faster due to the introduction of a locale
archive. Implemented by Roland McGrath and Ulrich Drepper.
* Startup times are significantly reduced by not using exported functions
inside the library itself. Changes by Jakub Jelinek, Roland McGrath,
and Ulrich Drepper.
* Steven Munroe contributed a port to PowerPC64/Linux.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This release of the library runs on the following targets:
i[3456]86-*-gnu GNU Hurd on Intel
i[3456]86-*-linux-gnu Linux-2.x on Intel
alpha*-*-linux-gnu Linux-2.x on DEC Alpha
powerpc-*-linux-gnu Linux and MkLinux on PowerPC systems
powerpc64-*-linux-gnu Linux-2.4.19+ on 64-bit PowerPC systems
sparc-*-linux-gnu Linux-2.x on SPARC
sparc64-*-linux-gnu Linux-2.x on UltraSPARC 64-bit
ia64-*-linux-gnu Linux-2.x on ia64
s390-*-linux-gnu Linux-2.x on IBM S/390
s390x-*-linux-gnu Linux-2.4+ on IBM S/390 64-bit
sh-*-linux-gnu Linux-2.x on Super Hitachi
x86-64-*-linux-gnu Linux-2.4+ on x86-64
The following targets should not be far away from being usable:
*-*-gnu GNU Hurd on platforms other than Intel
arm-*-linux-gnu Linux-2.x on ARM
cris-*-linux-gnu Linux-2.4+ on CRIS
hppa*-*-linux-gnu Linux-2.x on HP/PA
m68k-*-linux-gnu Linux-2.x on Motorola 680x0
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. 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.3. 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 25 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.3/configure ...options for configure...
Even though TLS support is mentioned as one new feature for this release
the default is not to build glibc with TLS support enabled. This has
several reasons, most of which are out of control of the glibc
developers. Therefore it is necessry to *not* use the --with-tls option
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. Starting with
this release the earliest accepted compiler is gcc 3.2. The configure
script will complain about any earlier compiler.
In case of problems with building glibc it is advised to first try the
very latest sources from the stable gcc 3.2 branch. The problems
might already have been fixed.
It is also important to get very recent binutils. For Linux this
normally means the releases by H.J. Lu which are available at
ftp://ftp.kernel.org/pub/linux/devel/binutils
Version 2.13.90.0.4 has been reported to work. Before reporting a bug
please make sure you are using a recent version.
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. Support for the new
autoconf will be enabled in upcoming releases.
To enable prelinking an additional package is needed. The prelink
program is available at
ftp://people.redhat.com/jakub/prelink/
The last version as of this writing is
prelink-20021002.tar.bz2
It should support all the not-embedded architectures but the demands
on recent tools and kernels might be high. Read the documentation
coming with the package. Your distribution of choice might already
have a package available, check it first.
On 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.3.x release should be binary compatible with the 2.2 and earlier
releases. All correct programs should continue to run. This does
*not* mean that programs compiled on a system running glibc 2.3.x will
run on systems with only glibc 2.2. Compatibility is always in one
direction. Systems with glibc 2.2 will not even attempt to run
binaries generated with glibc 2.3.x if this is not possible so there
is not much to worry about.
The locale files are now kept in an archive which guarantees much
faster access. Startup times of applications using setlocale() are
significantly improved. The locale archive is handled by the
localedef program just like ordinary compilation of locales. By
running
make localedata/install-locales
it is possible to generate an archive with all locales.
take a while. Using the -j option on SMP systems should help. It is
most of the time not necessary to install all locales. Just pick the
once which the users of the system will want to use.
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 are there not only to distribute
the workload, they also help to archive questions and answers. 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
ideally 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 among others:
Wolfram Gloger
Bruno Haible
Isamu Hasegawa
Andreas Jaeger
Jakub Jelinek
Kaz Kojima
H.J. Lu
Roland McGrath
Steven Munroe
Andreas Schwab
Franz Sirl
I want to thank all of them. Thanks also to the few dedicated
testers we have:
Kaoru Fukui
Jack Howarth
--
--------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
----- End forwarded message -----
--
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20021003/6564fc2f/attachment-0001.bin>
Подробная информация о списке рассылки Devel