From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulrich Drepper To: GNU libc testers , VGER gcc list , libc-announce@sources.redhat.com Subject: glibc 2.2.4 Date: Wed, 15 Aug 2001 22:24:00 -0000 Message-id: X-SW-Source: 2001/msg00000.html 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 `------------------------