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]

Re: announcement text



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]