diff options
| -rw-r--r-- | ChangeLog | 6 | ||||
| -rw-r--r-- | NEWS | 10 | ||||
| -rw-r--r-- | README | 45 | ||||
| -rw-r--r-- | README-alpha | 287 | ||||
| -rw-r--r-- | README.template | 43 | ||||
| -rw-r--r-- | version.h | 2 |
6 files changed, 30 insertions, 363 deletions
diff --git a/ChangeLog b/ChangeLog index 76ee5da9b8..7db9612f04 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,11 @@ 2004-12-19 Roland McGrath <roland@frob.com> + * version.h (VERSION): 2.3.4. + * README.template: Various updates. + * README: Regenerated. + * NEWS: Mention ports. + * README-alpha: File removed. + [BZ #416] * locale/langinfo.h: Comment fixes. diff --git a/NEWS b/NEWS index 236c4378f8..f73d3287c4 100644 --- a/NEWS +++ b/NEWS @@ -1,4 +1,4 @@ -GNU C Library NEWS -- history of user-visible changes. 2004-10-19 +GNU C Library NEWS -- history of user-visible changes. 2004-12-19 Copyright (C) 1992-2002,2003,2004 Free Software Foundation, Inc. See the end for copying conditions. @@ -40,7 +40,13 @@ Version 2.3.4 * Low-overhead boundary checking variants of string and some stdio functions were added. These are to be used in conjunction with a gcc patch by Jakub Jelinek which adds calls to these functions if possible. - Patch by Jakub Jelinek and Ulrich Drepper. + Implemented by Jakub Jelinek and Ulrich Drepper. + +* Old code for several operating systems and machine architectures that + have not been in working condition in a long time have been removed from + the main source tree maintained by the GNU C Library's maintainers. + These files are now reside in the separate `ports' source module + that is usable as an add-on when building the library. Version 2.3.3 diff --git a/README b/README index 69a712a6cf..36a2af9129 100644 --- a/README +++ b/README @@ -1,4 +1,4 @@ -This directory contains the version 2.3.3 release of the GNU C Library. +This directory contains the version 2.3.4 release of the GNU C Library. Many bugs have been fixed since the last release. Some bugs surely remain. @@ -21,39 +21,12 @@ configurations: 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 - cris-*-linux-gnu Linux-2.4+ on CRIS x86-64-*-linux-gnu Linux-2.4+ on x86-64 -Former releases of this library (version 1.09.1 and perhaps earlier -versions) used to run on the following configurations: - - alpha-dec-osf1 - i[3456]86-*-bsd4.3 - i[3456]86-*-isc2.2 - i[3456]86-*-isc3 - i[3456]86-*-sco3.2 - i[3456]86-*-sco3.2v4 - i[3456]86-*-sysv - i[3456]86-*-sysv4 - i[3456]86-force_cpu386-none - i[3456]86-sequent-bsd - i960-nindy960-none - m68k-hp-bsd4.3 - m68k-mvme135-none - m68k-mvme136-none - m68k-sony-newsos3 - m68k-sony-newsos4 - m68k-sun-sunos4 - mips-dec-ultrix4 - mips-sgi-irix4 - sparc-sun-solaris2 - sparc-sun-sunos4 - -Since no one has volunteered to test and fix the above configurations, -these are not supported at the moment. It's expected that these don't -work anymore. Porting the library is not hard. If you are interested -in doing a port, please contact the glibc maintainers by sending -electronic mail to <bug-glibc@gnu.org>. +Past releases of this library ran on a variety of configurations that are +no longer supported. Porting the library is not hard. If you are +interested in doing a port, please contact the glibc maintainers; +see http://www.gnu.org/software/libc/ for more information. There are some add-ons which can be used together with GNU libc. They are designed in a way to ease the installation by integrating them in @@ -76,11 +49,9 @@ The file NOTES contains a description of the feature-test macros used in the GNU C library, explaining how you can tell the library what facilities you want it to make available. -We prefer to get bug reports sent using the `glibcbug' shell script which -is installed together with the rest of the GNU libc to <bugs@gnu.org>. -Simply run this shell script and fill in the information. Nevertheless -you can still send bug reports to <bug-glibc@gnu.org> as normal electronic -mails. +Please see http://www.gnu.org/software/libc/bugs.html for bug reporting +information. We are now using the Bugzilla system to track all bug reports. +This web page gives detailed information on how to report bugs properly. The GNU C Library is free software. See the file COPYING.LIB for copying conditions, and LICENSES for notices about a few contributions that require diff --git a/README-alpha b/README-alpha deleted file mode 100644 index a2a15ddb23..0000000000 --- a/README-alpha +++ /dev/null @@ -1,287 +0,0 @@ - GNU libc SNAPSHOT SYSTEM - (general info) - Updated 1997-9-26 - -WHAT ARE GNU libc SNAPSHOTS ---------------------------- - -Snapshots are an "image" of the main glibc development tree, captured at a -particular random instant in time. When you use the snapshots, you should be -able to maintain a local copy of libc that is no more than one day older than -the official source tree used by the libc maintainers. - -The primary purpose of providing snapshots is to widen the group of motivated -developers that would like to help test, debug, and enhance glibc, by providing -you with access to the "latest and greatest" source. This has several -advantages, and several disadvantages. - - First the advantages: - - o Once we have a large base of motivated testers using the snapshots, - this should provide good coverage across all currently supported - glibc hosts and targets. If a new bug is introduced in glibc due to - fixing another bug or ongoing development, it should become - obvious much more quickly and get fixed before the next general - net release. This should help to reduce the chances of glibc being - released to the general public with a major bug that went unnoticed - during the release cycle testing because they are machine dependent. - We hope to greatly improve glibc's stability and reliability by - involving more people and more execution environments in the - prerelease testing. - - o With access to the latest source, any diffs that you send to fix - bugs or add new features should be much easier for the glibc team - to merge into the official source base (after suitable review - of course). This encourages us to merge your changes quicker, - while they are still "fresh". - - o Once your diffs are merged, you can obtain a new copy of glibc - containing your changes almost immediately. Thus you do not - have to maintain local copies of your changes for any longer - than it takes to get them merged into the official source base. - This encourages you to send in changes quicker. - - And the disadvantages: - - o The snapshot you get will be largely untested and of unknown quality. - It may fail to configure or compile. It may have serious bugs. - You should always keep a copy of the last known working version - before updating to the current snapshot, or at least be able to - regenerate a working version if the latest snapshot is unusable - in your environment for some reason. - - If a production version of glibc has a bug and a snapshot has the fix, - and you care about stability, you should put only the fix for that - particular problem into your production version. Of course, if you - are eager to test glibc, you can use the snapshot versions in your - daily work, but users who have not been consulted about whether they - feel like testing glibc should generally have something which is at - least as bug free as the last released version. - - o Providing timely response to your questions, bug reports, and - submitted patches will require the glibc development team to allocate - time from an already thin time budget. Please try to help us make - this time as productive as possible. See the section below about - how to submit changes. - - -WHO SHOULD TRY THE SNAPSHOTS ----------------------------- - -Remember, these are snapshots not tested versions. So if you use -these versions you should be able to - - o make sure your system stays usable - - o locate and hopefully fix problems - - o to port glibc to a new target yourself - -You should not use the snapshots if - - o your system is needed in a production environment which needs - stability - - o you expect us to fix your problems since you somehow depend on them. - You must be willing to fix the problems yourself, we don't want to - see "I have problems, fix this" messages. - - -HOW TO GET THE SNAPSHOTS ------------------------- - -At the moment we provide a full snapshot weekly (every sunday), so -that users getting a snapshot for the first time, or updating after -a long period of not updating, can get the latest version in a single -operation. Along with the full snapshot, we will provide incremental -diffs on a nearly daily basis (whenever code changes). Each daily -diff will be relative to the source tree after applying all previous -daily diffs. The daily diffs are for people who have relatively low -bandwidth ftp or uucp connections. - -The files will be available via anonymous ftp from alpha.gnu.org, in -directory /gnu/libc and on linux.kernel.org in /pub/software/libs/glibc. The -directories should look something like: - - libc-970921.tar.gz - libc-970917-970922.diff.gz - libc-970922-970925.diff.gz - . - . - . - -Please note that the snapshots on alpha.gnu.org and on -linux.kernel.org are not always in sync. Patches to some files might -appear a day a diff earlier or later on alpha than on kernel. -Use always alpha or always kernel but don't mix them. - -There are sometimes additionally test releases of the add-ons available in -these directories. If a new version of an add-on is available it is normally -required for the corresponding snapshot so always pay attention for these. - -Note that we provide GNU gzip compressed files only. You can ftp gzip -from ftp.gnu.org in directory pub/gnu. - -In some cases the dates for diffs and snapshots do not match like in the -example above. The full release is for 970921 but the patch is for -970917-970922. This only means that nothing changed between 970917 and 970922 -and that you have to use this patch on top of the 970921 snapshot since the -patch is made on 970922. - -Also, as the gcc developers did with their gcc snapshot system, even though we -will make the snapshots available on a publically accessible ftp area, we ask -that recipients not widely publicise their availability. The motivation for -this request is not to hoard them, but to avoid the situation where the -general glibc user base naively attempts to use the snapshots, has trouble with -them, complains publically, and the reputation of glibc declines because of a -perception of instability or lack of quality control. - - -GLIBC TEST SUITE ----------------- - -A test suite is distributed as an integral part of the snapshots. A simple -"make check" in your build directory is sufficient to run the tests. glibc -should pass all tests and if any fails, please report it. A failure might not -originate from a bug in glibc but also from bugs in the tools, e.g. with gcc -2.7.2.x the math tests fail some of the tests because of compiler bugs. - -Note that the test suite is still in its infancy. The tests themselves only -cover a small portion of libc features, and where tests do exist for a feature -they are not exhaustive. New tests are welcome. - - -GETTING HELP, GLIBC DISCUSSIONS, etc ------------------------------------- - -People who want to help with glibc and who test out snapshots -regularly should get on the libc-alpha@sourceware.cygnus.com mailing -list by sending an email to libc-alpha-subscribe@sourceware.cygnus.com. -This list is meant (as the name suggests) for the discussion of test -releases and also reports for them. People who are on this list are -welcome to post questions of general interest. - -People who are not only willing to test the snapshots but instead -really want to help developing glibc should contact -libc-hacker-subscribe@sourceware.cygnus.com.org to be put on the developers -mailing list. This list is really only meant for developers. No -questions about installation problems or other simple topics are -wanted nor will they be answered. - -Do *not* send any questions about the snapshots or patches specific to the -snapshots to bug-glibc@gnu.org. Nobody there will have any idea what -you are talking about and it will just cause confusion. - - -BUG REPORTS ------------ - -Send bug reports directly to Ulrich Drepper <drepper@gnu.org>. Please -do *not* use the glibcbug script for reporting bugs in the snapshots. -glibcbug should only be used for problems with the official released versions. -We don't like bug reports in the bug database because otherwise the impression -of instability or lack of quality control of glibc as a whole might manifest -in people's mind. - -Note that since no testing is done on the snapshots, and snapshots may even be -made when glibc is in an inconsistent state, it may not be unusual for an -occasional snapshot to have a very obvious bug, such as failure to compile on -*any* machine. It is likely that such bugs will be fixed by the next -snapshot, so it really isn't necessary to report them unless they persist for -a couple of days. - -Missing files should always be reported, since they usually mean there is a -problem with the snapshot-generating process and we won't know about them -unless someone tells us. - -Bugs which are non-obvious, such as failure to compile on only a specific -machine, a new machine dependent or obscure bug (particularly one not detected -by the testsuite), etc should be reported when you discover them, or have a -suggested patch to fix them. - - -FORMAT FOR PATCHES ------------------- - -If you have a fix for a bug, or an enhancement to submit, send your patch to -Ulrich Drepper <drepper@gnu.org>. Here are some simple guidelines for -submitting patches: - - o Use "unified diffs" for patches. A typical command for generating - context diffs is "diff -ru glibc-old glibc-patched". - - o Use the "minimalist approach" for patches. That is, each patch - should address only one particular bug, new feature, etc. Do not - save up many unrelated changes and submit them all in one big - patch, since in general, the larger the patch the more difficult - it is for us to decide if the patch is either correct or - desirable. And if we find something about the patch that needs - to be corrected before it can be installed, we would have to reject - the entire patch, which might contain changes which otherwise would - be accepted if submitted separately. - - o Submit a sample ChangeLog entry with your patch. See the existing - glibc ChangeLog for examples of what a ChangeLog entry should look - like. The emacs command ^X4A will create a ChangeLog entry header - for you. - - -BUILDING SNAPSHOTS ------------------- - -The `best' way to build glibc is to use an extra directory, e.g.: -tar xzf libc-970921.tar.gz -mkdir build-glibc -cd build-glibc -../libc-970921/configure ... - -In this way you can easily clean up (since `make clean' doesn't work at -the moment) and rebuild glibc. - - -NECESSARY TOOLS ---------------- - -For the recommended versions of gcc, binutils, make, texinfo, gettext, -autoconf and other tools which might be especially needed when using patches, -please read the file INSTALL. - - -HOW CAN YOU HELP ----------------- - -It helps already a lot if you just install glibc on your system and try to -solve any problems. You might want to look at the file `PROJECTS' and help -with one of those projects, fix some bugs (see `BUGS' or the bug database), -port to an unsupported platform, ... - - -FURTHER DOCUMENTATION ---------------------- - -A lot of questions are answered in the FAQ. The files `INSTALL', `README' and -`NOTES' contain the most important documentation. Furthermore glibc has its -own 700+ pages info documentation, ... - - - -And finally a word of caution: The libc is one of the most fundamental parts -of your system - and these snapshots are untested and come without any -guarantee or warranty. You might be lucky and everything works or you might -crash your system. If you install a glibc snapshot as primary library, you -should have a backup somewhere. - -On many systems it is also a problem to replace the libc while the system is -running. In the worst case on broken OSes some systems crash. On better -systems you can move the old libc aside but removing it will cause problems -since there are still processes using this libc image and so you might have to -check the filesystem to get rid of the libc data. One good alternative (which -is also safer) is to use a chroot'ed environment. - -Thanks for your help and support. - -Thanks to Fred Fish from Cygnus for the original version of this text -(for GDB). - - -Ulrich Drepper diff --git a/README.template b/README.template index 9b300a9226..d501d718df 100644 --- a/README.template +++ b/README.template @@ -21,39 +21,12 @@ configurations: 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 - cris-*-linux-gnu Linux-2.4+ on CRIS x86-64-*-linux-gnu Linux-2.4+ on x86-64 -Former releases of this library (version 1.09.1 and perhaps earlier -versions) used to run on the following configurations: - - alpha-dec-osf1 - i[3456]86-*-bsd4.3 - i[3456]86-*-isc2.2 - i[3456]86-*-isc3 - i[3456]86-*-sco3.2 - i[3456]86-*-sco3.2v4 - i[3456]86-*-sysv - i[3456]86-*-sysv4 - i[3456]86-force_cpu386-none - i[3456]86-sequent-bsd - i960-nindy960-none - m68k-hp-bsd4.3 - m68k-mvme135-none - m68k-mvme136-none - m68k-sony-newsos3 - m68k-sony-newsos4 - m68k-sun-sunos4 - mips-dec-ultrix4 - mips-sgi-irix4 - sparc-sun-solaris2 - sparc-sun-sunos4 - -Since no one has volunteered to test and fix the above configurations, -these are not supported at the moment. It's expected that these don't -work anymore. Porting the library is not hard. If you are interested -in doing a port, please contact the glibc maintainers by sending -electronic mail to <bug-glibc@gnu.org>. +Past releases of this library ran on a variety of configurations that are +no longer supported. Porting the library is not hard. If you are +interested in doing a port, please contact the glibc maintainers; +see http://www.gnu.org/software/libc/ for more information. There are some add-ons which can be used together with GNU libc. They are designed in a way to ease the installation by integrating them in @@ -76,11 +49,9 @@ The file NOTES contains a description of the feature-test macros used in the GNU C library, explaining how you can tell the library what facilities you want it to make available. -We prefer to get bug reports sent using the `glibcbug' shell script which -is installed together with the rest of the GNU libc to <bugs@gnu.org>. -Simply run this shell script and fill in the information. Nevertheless -you can still send bug reports to <bug-glibc@gnu.org> as normal electronic -mails. +Please see http://www.gnu.org/software/libc/bugs.html for bug reporting +information. We are now using the Bugzilla system to track all bug reports. +This web page gives detailed information on how to report bugs properly. The GNU C Library is free software. See the file COPYING.LIB for copying conditions, and LICENSES for notices about a few contributions that require diff --git a/version.h b/version.h index 07d0ac72f6..4eeb1cceb3 100644 --- a/version.h +++ b/version.h @@ -1,4 +1,4 @@ /* This file just defines the current version number of libc. */ #define RELEASE "stable" -#define VERSION "2.3.3" +#define VERSION "2.3.4" |