Update.

1999-02-02  Ulrich Drepper  <drepper@cygnus.com>

	* sysdeps/unix/sysv/linux/reboot.c: Make sure first parameter is
	correctly passed to the kernel even on 64bit platforms.
	Patch by Bruce Elliott <bde@nwlink.com>.

	* localedata/locales/it_CH: New file.
	Contributed by Giacomo Amabile Catenazzi <gcatenaz@g26.ethz.ch>.

ChangeLog

@@ -1,3 +1,12 @@
+1999-02-02  Ulrich Drepper  <drepper@cygnus.com>
+
+	* sysdeps/unix/sysv/linux/reboot.c: Make sure first parameter is
+	correctly passed to the kernel even on 64bit platforms.
+	Patch by Bruce Elliott <bde@nwlink.com>.
+
+	* localedata/locales/it_CH: New file.
+	Contributed by Giacomo Amabile Catenazzi <gcatenaz@g26.ethz.ch>.
+
 1999-01-31  Ulrich Drepper  <drepper@cygnus.com>
 
 	* math/libm-test.c (fdim_test): Fix typo in message.

FAQ

@@ -39,7 +39,7 @@ please let me know.
 1.14.	Why do I get messages about missing thread functions when I use
 	librt?  I don't even use threads.
 1.15.	What's the problem with configure --enable-omitfp?
-1.16.	I get failures during `make check'.  What shall I do?
+1.16.	I get failures during `make check'.  What should I do?
 1.17.	What is symbol versioning good for?  Do I need it?
 
 2. Installation and configuration issues
@@ -213,7 +213,7 @@ EGCS and with GCC 2.8.1. See question 2.8 for details.
 1.3.	When I try to compile glibc I get only error messages.
 	What's wrong?
 
-{UD} You definitely need GNU make to translate GNU libc.  No other make
+{UD} You definitely need GNU make to build GNU libc.  No other make
 program has the needed functionality.
 
 We recommend version GNU make version 3.75 or 3.77.  Versions before 3.75
@@ -317,7 +317,7 @@ when using the library do not need to match.  The GNU C library runs without
 problems on kernels that are older than the kernel headers used.  The other
 way round (compiling the GNU C library with old kernel headers and running
 on a recent kernel) does not necessarily work.  For example you can't use
-new kernel features when using old kernel headers for compiling the GNU C
+new kernel features if you used old kernel headers to compile the GNU C
 library.
 
 {ZW} Even if you are using a 2.0 kernel on your machine, we recommend you
@@ -438,19 +438,19 @@ with a library that was build this way, we advise you to rebuild the library
 without --enable-omitfp.  If the problem vanishes consider tracking the
 problem down and report it as compiler failure.
 
-Since a library build with --enable-omitfp is undebuggable on most systems,
-debuggable libraries are also built - you can use it by appending "_g" to
+Since a library built with --enable-omitfp is undebuggable on most systems,
+debuggable libraries are also built - you can use them by appending "_g" to
 the library names.
 
 The compilation of these extra libraries and the compiler optimizations slow
 down the build process and need more disk space.
 
 
-1.16.	I get failures during `make check'.  What shall I do?
+1.16.	I get failures during `make check'.  What should I do?
 
-{AJ} The testsuite should compile and run cleanly on your system, every
-failure should be looked into.  Depending on the failure I wouldn't advise
-installing the library at all.
+{AJ} The testsuite should compile and run cleanly on your system; every
+failure should be looked into.  Depending on the failures, you probably
+should not install the library at all.
 
 You should consider using the `glibcbug' script to report the failure,
 providing as much detail as possible.  If you run a test directly, please
@@ -460,13 +460,15 @@ command line which failed and run the test from the subdirectory for this
 test in the sources.
 
 There are some failures which are not directly related to the GNU libc:
-- Some compiler produce buggy code.  The egcs 1.1 release should be ok.  gcc
-  2.8.1 might cause some failures, gcc 2.7.2.x is so buggy, that explicit
-  checks have been used so that you can't build with it.
+- Some compilers produce buggy code.  No compiler gets single precision
+  complex numbers correct on Alpha.  Otherwise, the egcs 1.1 release should be
+  ok; gcc 2.8.1 might cause some failures; gcc 2.7.2.x is so buggy that
+  explicit checks have been used so that you can't build with it.
 - The kernel might have bugs.  For example on Linux/Alpha 2.0.34 the
   floating point handling has quite a number of bugs and therefore most of
   the test cases in the math subdirectory will fail.  Linux 2.2 has
-  fixes for the floating point support on Alpha.
+  fixes for the floating point support on Alpha.  The Linux/SPARC kernel has
+  also some bugs in the FPU emulation code (as of Linux 2.2.0).
 
 
 1.17.	What is symbol versioning good for?  Do I need it?
@@ -476,15 +478,15 @@ changes.  One version of an interface might have been introduced in a
 previous version of the GNU C library but the interface or the semantics of
 the function has been changed in the meantime.  For binary compatibility
 with the old library, a newer library needs to still have the old interface
-for old programs.  On the other hand new programs should use the new
+for old programs.  On the other hand, new programs should use the new
 interface.  Symbol versioning is the solution for this problem.  The GNU
-libc version 2.1 uses by default symbol versioning if the binutils support
-it.
+libc version 2.1 uses symbol versioning by default if the installed binutils
+supports it.
 
-We don't advise to build without symbol versioning since you lose binary
-compatibility if you do - for ever!  The binary compatibility you lose is
-not only against the previous version of the GNU libc (version 2.0) but also
-against future versions.
+We don't advise building without symbol versioning, since you lose binary
+compatibility - forever!  The binary compatibility you lose is not only
+against the previous version of the GNU libc (version 2.0) but also against
+all future versions.
 
 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

FAQ.in

@@ -69,7 +69,7 @@ EGCS and with GCC 2.8.1. See ?exception for details.
 ??	When I try to compile glibc I get only error messages.
 	What's wrong?
 
-{UD} You definitely need GNU make to translate GNU libc.  No other make
+{UD} You definitely need GNU make to build GNU libc.  No other make
 program has the needed functionality.
 
 We recommend version GNU make version 3.75 or 3.77.  Versions before 3.75
@@ -168,7 +168,7 @@ when using the library do not need to match.  The GNU C library runs without
 problems on kernels that are older than the kernel headers used.  The other
 way round (compiling the GNU C library with old kernel headers and running
 on a recent kernel) does not necessarily work.  For example you can't use
-new kernel features when using old kernel headers for compiling the GNU C
+new kernel features if you used old kernel headers to compile the GNU C
 library.
 
 {ZW} Even if you are using a 2.0 kernel on your machine, we recommend you
@@ -282,18 +282,18 @@ with a library that was build this way, we advise you to rebuild the library
 without --enable-omitfp.  If the problem vanishes consider tracking the
 problem down and report it as compiler failure.
 
-Since a library build with --enable-omitfp is undebuggable on most systems,
-debuggable libraries are also built - you can use it by appending "_g" to
+Since a library built with --enable-omitfp is undebuggable on most systems,
+debuggable libraries are also built - you can use them by appending "_g" to
 the library names.
 
 The compilation of these extra libraries and the compiler optimizations slow
 down the build process and need more disk space.
 
-??	I get failures during `make check'.  What shall I do?
+??	I get failures during `make check'.  What should I do?
 
-{AJ} The testsuite should compile and run cleanly on your system, every
-failure should be looked into.  Depending on the failure I wouldn't advise
-installing the library at all.
+{AJ} The testsuite should compile and run cleanly on your system; every
+failure should be looked into.  Depending on the failures, you probably
+should not install the library at all.
 
 You should consider using the `glibcbug' script to report the failure,
 providing as much detail as possible.  If you run a test directly, please
@@ -303,13 +303,15 @@ command line which failed and run the test from the subdirectory for this
 test in the sources.
 
 There are some failures which are not directly related to the GNU libc:
-- Some compiler produce buggy code.  The egcs 1.1 release should be ok.  gcc
-  2.8.1 might cause some failures, gcc 2.7.2.x is so buggy, that explicit
-  checks have been used so that you can't build with it.
+- Some compilers produce buggy code.  No compiler gets single precision
+  complex numbers correct on Alpha.  Otherwise, the egcs 1.1 release should be
+  ok; gcc 2.8.1 might cause some failures; gcc 2.7.2.x is so buggy that
+  explicit checks have been used so that you can't build with it.
 - The kernel might have bugs.  For example on Linux/Alpha 2.0.34 the
   floating point handling has quite a number of bugs and therefore most of
   the test cases in the math subdirectory will fail.  Linux 2.2 has
-  fixes for the floating point support on Alpha.
+  fixes for the floating point support on Alpha.  The Linux/SPARC kernel has
+  also some bugs in the FPU emulation code (as of Linux 2.2.0).
 
 ??	What is symbol versioning good for?  Do I need it?
 
@@ -318,15 +320,15 @@ changes.  One version of an interface might have been introduced in a
 previous version of the GNU C library but the interface or the semantics of
 the function has been changed in the meantime.  For binary compatibility
 with the old library, a newer library needs to still have the old interface
-for old programs.  On the other hand new programs should use the new
+for old programs.  On the other hand, new programs should use the new
 interface.  Symbol versioning is the solution for this problem.  The GNU
-libc version 2.1 uses by default symbol versioning if the binutils support
-it.
+libc version 2.1 uses symbol versioning by default if the installed binutils
+supports it.
 
-We don't advise to build without symbol versioning since you lose binary
-compatibility if you do - for ever!  The binary compatibility you lose is
-not only against the previous version of the GNU libc (version 2.0) but also
-against future versions.
+We don't advise building without symbol versioning, since you lose binary
+compatibility - forever!  The binary compatibility you lose is not only
+against the previous version of the GNU libc (version 2.0) but also against
+all future versions.
 
 
 ? Installation and configuration issues

locale/programs/locale-spec.c

@@ -80,7 +80,7 @@ locale_special (const char *name, int show_category_name,
 		      if (ch != EOF)
 			putchar (ch);
 		      else
-			fputs ("<???\>", stdout);
+			fputs ("<??\?>", stdout);
 		    }
 
 		  putchar ('"');

localedata/locales/it_CH

@@ -0,0 +1,74 @@
+comment_char %
+escape_char  /
+repertoiremap mnemonic.ds
+%
+% Italian Language Locale for Switzerland
+% Language: it
+% Territory: CH
+% Revision: ........
+% Date: 1999-01-21
+% Users: general
+% Repertoiremap: mnemonic.ds
+% Charset: ISO-8859-1
+% Distribution and use is free, also
+% for commercial purposes.
+
+LC_CTYPE
+copy "en_DK"
+END LC_CTYPE
+
+LC_COLLATE
+copy "en_DK"
+END LC_COLLATE
+
+LC_MESSAGES
+yesexpr "<'/>><<(><s><S><j><J><o><O><y><Y><)/>><.><*>"
+noexpr  "<'/>><<(><n><N><)/>><.><*>"
+END LC_MESSAGES
+
+LC_MONETARY
+copy  "de_CH"
+END LC_MONETARY
+
+LC_NUMERIC
+decimal_point             "<,>"
+thousands_sep             "<apostrophe>"
+grouping                  3;3
+END LC_NUMERIC
+
+LC_TIME
+abday   "<d><o><m>";"<l><u><n>";/
+        "<m><a><r>";"<m><e><r>";/
+        "<g><i><o>";"<v><e><n>";/
+        "<s><a><b>"
+day     "<d><o><m><e><n><i><c><a>";/
+        "<l><u><n><e><d><i!>";/
+        "<m><a><r><t><e><d><i!>";/
+        "<m><e><r><c><o><l><e><d><i!>";/
+        "<g><i><o><v><e><d><i!>";/
+        "<v><e><n><e><r><d><i!>";/
+        "<s><a><b><a><t><o>"
+abmon   "<g><e><n>";"<f><e><b>";/
+        "<m><a><r>";"<a><p><r>";/
+        "<m><a><g>";"<g><i><u>";/
+        "<l><u><g>";"<a><g><o>";/
+        "<s><e><t>";"<o><t><t>";/
+        "<n><o><v>";"<d><i><c>"
+mon     "<g><e><n><n><a><i><o>";/
+        "<f><e><b><b><r><a><i><o>";/
+        "<m><a><r><z><o>";/
+        "<a><p><r><i><l><e>";/
+        "<m><a><g><g><i><o>";/
+        "<g><i><u><g><n><o>";/
+        "<l><u><g><l><i><o>";/
+        "<a><g><o><s><t><o>";/
+        "<s><e><t><t><e><m><b><r><e>";/
+        "<o><t><t><o><b><r><e>";/
+        "<n><o><v><e><m><b><r><e>";/
+        "<d><i><c><e><m><b><r><e>"
+d_t_fmt "<%><a><SP><%><d><SP><%><b><SP><%><Y><SP><%><T><SP><%><Z>"
+d_fmt   "<%><d><.><SP><%><m><.><SP><%><y>"
+t_fmt   "<%><T>"
+am_pm   "";""
+t_fmt_ampm ""
+END LC_TIME

manual/install.texi

@@ -48,10 +48,9 @@ GNU Make, and possibly others.  @xref{Tools for Compilation}, below.
 @cindex configuring
 @cindex compiling
 
-GNU Libc cannot be compiled in the source directory.  You must create a
-separate directory for the object files.  This directory should be
-outside the source tree.  For example, if you have unpacked the glibc
-sources in @file{/src/gnu/glibc-2.1.0}, create a directory
+GNU Libc can be compiled in the source directory but we'd advise to
+build in a separate build directory.  For example, if you have unpacked
+the glibc sources in @file{/src/gnu/glibc-2.1.0}, create a directory
 @file{/src/gnu/glibc-build} to put the object files in.
 
 From your object directory, run the shell script @file{configure} found