This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Ulrich- Here is a diff of edits to the announce document; I can send you the edited text if need be (diif -e or whatever). I have mostly done syntax and other readability changes. cheers, Mark $diff announce.edited ANNOUNCE 56,62c56,61 < to damage one's system. Therefore persons who do not exactly know < what to do should consider using a binary distribution instead, when < they become available. We recommend that all Linux distributors < base their next release on glibc 2.2. < < The system requirements for building glibc from the source are another < reason to avoid using this method: on Intel platforms the full --- > to damage one's system. Therefore, persons who do not exactly know > what to do, should consider using a binary distribution instead, when > they become 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 65,67c64,66 < the compiler will need large amounts of virtual memory, on the order < of 100MB on Intel and 200MB on Alpha. If the `-j' option of make < is used, these numbers grow linearly. Building the complete --- > 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 69,71c68,70 < adds another 8 minutes. On slower or un-tuned systems the < times are very much higher and it can possibly take several days on < older systems. The use of the -j option for make is very --- > 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 use of the -j option for make is very 74c73 < In case you decide to compile glibc yourself you should read the --- > In case you decide to compile glibc yourself you need to read the 76c75 < are necessary. The most important tool is the compiler: although --- > are necessary. The most important one is the compiler. Although 88,92c87,90 < If you wish to compile or work with glibc sources on architectures < which are newly supported, you most probably need some development < version of the tools. The requirements for MIPS are described in < the FAQ. For others contact the developers working on tools for < the specific architecture. --- > Architectiure which are supported for a short time only you most > probably need some development version of the tools. The requirements > for MIPS are described in the FAQ. For others contact the developers > working on tools for the specific architecture. 95c93 < On systems with newer Linux kernels the configure script has a new option --- > One Linux systems the configure script has a new option 97,102c95,101 < options allows you to strip out code for compatibility with older kernel < versions. This is of interest since configuring for a 2.4.0 kernel < reduces the libc size by about 1%. This is not a high percentage but all < the code size reduced is in the most often used functions. Performance < is enhanced with this option, at the expense of incompatibility with < older kernels. If you never expect to run kernel versions older than --- > options allows to strip out code for compatibility with older kernel > versions. This is 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 105c104 < older kernel applications won't even start and the whole system might be --- > older kernel program won't even start and the whole system might be 110,113c109,113 < releases. Application binaries built with glibc 2.1 and earlier should < run on systems using glibc 2.2. However, application binaries built using < glibc 2.2 will not run on systems using earlier version of glibc, and in < fact will not even load. --- > releases. All programs should continue to run. This does *not* mean > that programs compiled on a system running glibc 2.2 will run on > system only have glibc 2.1 available. 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. END Mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |