FYI ----- Forwarded message from Ulrich Drepper ----- Date: Thu, 03 Oct 2002 03:09:57 -0700 From: Ulrich Drepper 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 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