Re: glibc 2.3

["Mike Black" <mblack@csi-inc.com>]

OK...now I'm confused:
configure says:
*** On GNU/Linux systems the GNU C Library should not be installed into
*** /usr/local since this might make your system totally unusable.
*** We strongly advise to use a different prefix.  For details read the FAQ.
*** If you really mean to do this, run configure again using the extra
*** parameter `--disable-sanity-checks'.
And the FAQ says the opposite:
{ZW} If you wish to be cautious, do not configure with --prefix=/usr.  If
you don't specify a prefix, glibc will be installed in /usr/local, where it
will probably not break anything.  (If you wish to be certain, set the
prefix to something like /usr/local/glibc2 which is not used for anything.)

It appears configure is using prefix /usr/local and spits out a bogus message.

----- Original Message ----- 
From: "Ulrich Drepper" <drepper@redhat.com>
To: <libc-alpha@sources.redhat.com>; <linux-gcc@vger.kernel.org>
Sent: Thursday, October 03, 2002 6:09 AM
Subject: glibc 2.3


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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 <ifaddrs.h> 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 `---------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQE9nBd12ijCOnn/RHQRAk6YAKCzhwbMdsXaLo2d42ZCvUyqP9SKzgCgkYtT
> TZrS2FWhkeVCV/WtEFvwaKE=
> =GgNw
> -----END PGP SIGNATURE-----
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-gcc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html