glibc 2.2

[Ulrich Drepper]

Release 2.2 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.tar.bz2               (~10MB, also .gz w/ ~14MB)
        glibc-linuxthreads-2.2.tar.bz2  (also .gz)
        nss_db-2.2.tar.gz
        nss_lwres-0.91.tar.gz

There is no patch for the glibc 2.1.3 sources since this would be
larger than the complete 2.2 sources themselves.  For those who
have downloaded 2.1.97 there is a patch available.


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?!)


The 2.2 release is the result of almost two years of work and includes
thousands of changes, significant improvements and bug fixes.  The
interface is almost complete with respect to current Unix standards.
This version of the library is believed to be more stable than any
previous release and therefore users of previous releases are strongly
advised to upgrade.  There are no known compatibility problems (except
if a program relies on bugs in previous releases; that is the program's
problem).

*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.  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 on a address@hidden system takes about 37 minutes, checking
adds another 8 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 written to allow this (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/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.2
to compile glibc (on some platforms more recent compilers are
required).  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.  In case a
compilation fails and the compiler is not 2.95.2 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.


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.0 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 release should be binary compatible with the 2.1 and earlier
releases.  All programs should continue to run.  This does *not* mean
that programs compiled on a system running glibc 2.2 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 so there is not much to worry about.

The internal locale format has been changed.  All locale information
has to be regenerated with localedef.  If you are upgrading a live
system 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.

One package which is problematic to compile when glibc 2.2 is
installed is gcc 2.95.2 (or earlier versions, but they should not be
used).  This is due to wrong use of a certain type in the libio in gcc
and some new symbols in public headers.  The problems are removed for
upcoming releases and a patch with instructions for 2.95.2 can be
found at

        http://clisp.cons.org/~haible/glibc22-HOWTO.html


Problems should all be reported using the `glibcbug' shell script.  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

simply 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
address@hidden mailing list.


Over the last two years many people helped by contributing code,
reporting bugs, sending patches.  I cannot mention them all here but
sure want to mention those who continuously helped all the time.  In
purely random order:

        Andreas Jaeger
        Andreas Schwab
        Bruno Haible
        Cristian Gafton
        Geoff Keating
        H.J. Lu
        Jakub Jelinek
        Kaz Kylheku
        Mark Kettenis
        Philip Blundell
        Richard Henderson
        Roland McGrath
        Thorsten Kukuk
        Zack Weinberg

The list with the changes below contains a few more names.  Please
remember those names for the day you have the opportunity to thank
them.


Finally, the (certainly incomplete) list of significant changes:

* Greg McGary added runtime support for bounds checking using gcc's
  new -fbounded-pointers option.  ix86 target is complete.  PowerPC
  is in progress.

* Thorsten Kukuk added secure mode support to nscd.

* The Berkeley db libraries have been removed.  They can be installed
  separately.

  Related, the nss_db module is now in a separate package since it
  obviously requires a database library being available.

* Wide character I/O streams implemented by Ulrich Drepper.

* Functions from the extended socket API added by Ulrich Drepper.

* Functions feenableexcept and fedisableexcept to control the
  behaviour of individual exceptions have been added by Andreas Jaeger.

* ldconfig program added by Andreas Jaeger and Jakub Jelinek.

* The resolver code has been updated from bind 8.2.3-T5B which supports
  threads.  The integration was done by Andreas Jaeger, Adam D. Bradley,
  and Mark Kettenis.

  This change could in some situations effect backward compatibility.  Since
  now `_res' is a thread-local instead of a global variable, modifying it
  in one thread does not have any effect in other threads.

  The resolver library was also extended to allow IPv6 as the transport
  protocol for the requests.  This work was done by Stig Venaas.

* Compatibility code for K&R C compilers has been removed from the
  header files.  A ISO C compiler is needed to use the library
  (conforming to either C89 or C99 standard).

* Complete rewrite of the localedef program to support multibyte character
  sets.  Implement handling of ISO 14651 and ISO 14652.  Rewrite strcoll,
  strxfrm, wcscoll, and wcsxfrm functions.  Make isw*() functions work.
  Implemented by Ulrich Drepper.

  Bruno Haible significantly improved the generation and use of the data
  structures for the wide character tables.

* Plural handling in gettext implemented by Ulrich Drepper.

* The utmp daemon has been removed.

* The port to MIPS-Linux has been finished by Andreas Jaeger.

* A port to Hitachi SH3 and SH4 has been contributed by Kazumoto Kojima
  and Yutaka Niibe.

* POSIX clocks and timers implemented by Kaz Kylheku and Ulrich Drepper.

* POSIX barriers implemented by Kaz Kylheku.

* POSIX spawn function family implemented by Ulrich Drepper.

* POSIX spinlocks are now available.

* Timed wait functions for mutex, rwlock, and semaphores are implemented.

* The configure option --enable-kernel=X.Y.Z allows to strip out
  compatibility for kernel versions before X.Y.Z.  This is currently only
  implemented for Linux.

* The sockaddr_in6 structure changed.  The IPv6 working group added a new
  field sin6_scope_id.  This means that all programs using IPv6 should be
  recompiled.  Don't expect binary compatibility with previous glibc
  versions.

* Various conversion modules for IBM character sets contributed by
  Masahide Washizawa.

* IA-64 port by Jes Sorensen and HJ Lu.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------