Update.cvs/libc-971205

1997-12-05 00:01  Ulrich Drepper  <drepper@cygnus.com>

	The kernel expects the arguments in a different order.
	* sysdeps/unix/sysv/linux/i386/s_pread64.S: New file.
	* sysdeps/unix/sysv/linux/i386/s_pwrite64.S: New file.

	* FAQ.in: New file.
	* gen-FAQ.pl: New file.
	* Makefile (FAQ): Add rule to generate from FAQ.in.

	* iconvdata/Makefile: Treat libJIS like the other modules.

	* rt/librt.map: New file.

	* sysdeps/wordsize-32/bits/environments.h: Add test for direct
	inclusion.
	* sysdeps/wordsize-64/bits/environments.h: Likewise.  Correct
	comment.

1997-12-04 22:29  Ulrich Drepper  <drepper@cygnus.com>

	* sysdeps/unix/sysv/linux/rt_sigprocmask.c: Fix prototype.
	* sysdeps/unix/sysv/linux/rt_sigsuspend.c: Likewise.
	* sysdeps/unix/sysv/linux/rt_sigqueueinfo.c: Include <sys/types.h>.
	Patches by Thorsten Kukuk <kukuk@weber.uni-paderborn.de>.

1997-11-27  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* string/bits/string2.h: Fix spellings.

	* string/string.h: Fix spellings.

1997-12-04  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* sysdeps/unix/sysv/linux/i386/sigaction.c: Rename extern
	declaration to __syscall_rt_sigaction.

	* sysdeps/unix/sysv/linux/sigreturn.c: Remove inclusion of
	non-existant <sigcontext.h>.

1997-12-04  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* sysdeps/generic/enbl-secure.c (__libc_init_secure): Correct
	typo.

1997-12-04  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* sysdeps/wordsize-64/bits/environments.h: Correct spelling.

	* Makeconfig (shared-thread-library): Correct spelling.

	* sysdeps/unix/sysv/linux/sys/pci.h: Include <linux/pci.h> and not
	<asm/pci.h>.

1997-12-04  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* sysdeps/unix/sysv/linux/bits/socket.h: Add AF_* and PF_
	constants from Linux headers. Pointed out by
	csmall@scooter.o.i.net. [PR libc/369]

1997-12-04 10:21  Thorsten Kukuk  <kukuk@vt.uni-paderborn.de>

	* sunrpc/xcrypt.c: Fix lower/upper characters in optimized hexval.

1997-12-04 00:06  Zack Weinberg  <zack@rabi.phys.columbia.edu>

	* configure.in: If --enable-add-ons is given without an
	argument, set the addons list to all subdirs with a configure
	script.

1 files changed, 787 insertions, 0 deletions

diff --git a/FAQ.in b/FAQ.in
new file mode 100644
index 0000000..770bef4
--- /dev/null
+++ b/FAQ.in
@@ -0,0 +1,787 @@
+	    Frequently Asked Questions about the GNU C Library
+
+This document tries to answer questions a user might have when
+installing and using glibc.  Please make sure you read this before
+sending questions or bug reports to the maintainers.
+
+The GNU C library is very complex.  The installation process has not
+been completely automated; there are too many variables. You can do
+substantial damage to your system by installing the library
+incorrectly.  Make sure you understand what you are undertaking before
+you begin.
+
+If you have any questions you think should be answered in this document,
+please let me know.
+
+						  --drepper@cygnus.com
+
+? Compiling glibc
+
+??	What systems does the GNU C Library run on?
+
+{UD} This is difficult to answer.  The file `README' lists the
+architectures GNU libc was known to run on *at some time*.  This does
+not mean that it still can be compiled and run on them now.
+
+The systems glibc is known to work on as of this release, and most
+probably in the future, are:
+
+	*-*-gnu			GNU Hurd
+	i[3456]86-*-linux-gnu	Linux-2.0 on Intel
+	m68k-*-linux-gnu	Linux-2.0 on Motorola 680x0
+	alpha-*-linux-gnu	Linux-2.0 on DEC Alpha
+	powerpc-*-linux-gnu     Linux and MkLinux on PowerPC systems
+	sparc-*-linux-gnu	Linux-2.0 on SPARC
+	sparc64-*-linux-gnu	Linux-2.0 on UltraSPARC
+
+Ports to other Linux platforms are in development, and may in fact
+work already, but no one has sent us success reports for them.
+Currently no ports to other operating systems are underway, although a
+few people have expressed interest.
+
+If you have a system not listed above (or in the `README' file) and
+you are really interested in porting it, contact
+
+	<bug-glibc@prep.ai.mit.edu>
+
+??	What compiler do I need to build GNU libc?
+
+{UD} You must use GNU CC to compile GNU libc.  A lot of extensions of
+GNU CC are used to increase portability and speed.
+
+GNU CC is found, like all other GNU packages, on
+	ftp://prep.ai.mit.edu/pub/gnu
+and the many mirror sites.  prep is always overloaded, so try to find
+a local mirror first.
+
+You always should try to use the latest official release.  Older
+versions may not have all the features GNU libc requires.  On most
+supported platforms, 2.7.2.3 is the earliest version that works at all.
+
+??	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 program has the needed functionality.
+
+We recommend version GNU make version 3.75.  Versions 3.76 and 3.76.1
+have bugs which appear when building big projects like GNU libc.
+Versions before 3.74 have bugs and/or are missing features.
+
+??	Do I need a special linker or archiver?
+
+{UD} You may be able to use your system linker, but GNU libc works
+best with GNU binutils.
+
+On systems where the native linker does not support weak symbols you
+will not get a fully ISO C compliant C library.  Generally speaking
+you should use the GNU binutils if they provide at least the same
+functionality as your system's tools.
+
+Always get the newest release of GNU binutils available.  Older
+releases are known to have bugs that prevent a successful compilation.
+
+{ZW} As of release 2.1 a linker supporting symbol versions is
+required.  For Linux, get binutils-2.8.1.0.17 or later.  Other systems
+may have native linker support, but it's moot right now, because glibc
+has not been ported to them.
+
+??	Do I need some more things to compile GNU C Library?
+
+{UD} Yes, there are some more :-).
+
+* GNU gettext.  This package contains the tools needed to construct
+  `message catalog' files containing translated versions of system
+  messages. See ftp://prep.ai.mit.edu/pub/gnu or better any mirror
+  site.  (We distribute compiled message catalogs, but they may not be
+  updated in patches.)
+
+* Some files depend on special tools.  E.g., files ending in .gperf
+  need a `gperf' program.  The GNU version (part of libg++) is known
+  to work while some vendor versions do not.
+
+  You should not need these tools unless you change the source files.
+
+* When compiling for Linux, the header files of the Linux kernel must
+  be available to the compiler as <linux/*.h> and <asm/*.h>.
+
+* lots of disk space (~170MB for i?86-linux; more for RISC platforms).
+
+* plenty of time.  Compiling just the shared and static libraries for
+  i?86-linux takes approximately 1h on an i586@133, or 2.5h on
+  i486@66, or 4.5h on i486@33.  Multiply this by 1.5 or 2.0 if you
+  build profiling and/or the highly optimized version as well.  For
+  Hurd systems times are much higher.
+
+  You should avoid compiling in a NFS mounted filesystem.  This is
+  very slow.
+
+  James Troup <J.J.Troup@comp.brad.ac.uk> reports a compile time of
+  45h34m for a full build (shared, static, and profiled) on
+  Atari Falcon (Motorola 68030 @ 16 Mhz, 14 Mb memory) and 22h48m
+  on Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory)
+
+  If you have some more measurements let me know.
+
+??	When I run `nm -u libc.so' on the produced library I still
+	find unresolved symbols.  Can this be ok?
+
+{UD} Yes, this is ok.  There can be several kinds of unresolved
+symbols:
+
+* magic symbols automatically generated by the linker.  These have names
+  like __start_* and __stop_*
+
+* symbols starting with _dl_* come from the dynamic linker
+
+* symbols resolved by using libgcc.a
+  (__udivdi3, __umoddi3, or similar)
+
+* weak symbols, which need not be resolved at all (fabs for example)
+
+Generally, you should make sure you find a real program which produces
+errors while linking before deciding there is a problem.
+
+??addon	What are these `add-ons'?
+
+{UD} To avoid complications with export rules or external source
+code some optional parts of the libc are distributed as separate
+packages (e.g., the crypt package, see ?crypt).
+
+To use these packages as part of GNU libc, just unpack the tarfiles in
+the libc source directory and tell the configuration script about them
+using the --enable-add-ons option.  If you give just --enable-add-ons
+configure tries to find all the add-on packages in your source tree.
+This may not work.  If it doesn't, or if you want to select only a
+subset of the add-ons, give a comma-separated list of the add-ons to
+enable:
+
+	configure --enable-add-ons=crypt,linuxthreads
+
+for example.
+
+Add-ons can add features (including entirely new shared libraries),
+override files, provide support for additional architectures, and
+just about anything else.  The existing makefiles do most of the work;
+only some few stub rules must be written to get everything running.
+
+??	My XXX kernel emulates a floating-point coprocessor for me.
+	Should I enable --with-fp?
+
+{ZW} An emulated FPU is just as good as a real one, as far as the C
+library is concerned.  You only need to say --without-fp if your
+machine has no way to execute floating-point instructions.
+
+People who are interested in squeezing the last drop of performance
+out of their machine may wish to avoid the trap overhead, but this is
+far more trouble than it's worth: you then have to compile
+*everything* this way, including the compiler's internal libraries
+(libgcc.a for GNU C), because the calling conventions change.
+
+??	When compiling GNU libc I get lots of errors saying functions
+	in glibc are duplicated in libgcc.
+
+{EY} This is *exactly* the same problem that I was having.  The
+problem was due to the fact that configure didn't correctly detect
+that the linker flag --no-whole-archive was supported in my linker.
+In my case it was because I had run ./configure with bogus CFLAGS, and
+the test failed.
+
+One thing that is particularly annoying about this problem is that
+once this is misdetected, running configure again won't fix it unless
+you first delete config.cache.
+
+{UD} Starting with glibc-2.0.3 there should be a better test to avoid
+some problems of this kind.  The setting of CFLAGS is checked at the
+very beginning and if it is not usable `configure' will bark.
+
+??	What's the problem with configure --enable-omitfp?
+
+{AJ} When --enable-omitfp is set the libraries are built without frame
+pointers. Some compilers produce buggy code for this model and
+therefore we don't advise using it at the moment.
+
+If you use --enable-omitfp, you're on your own. If you encounter
+problems 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 the library names.
+
+The compilation of these extra libraries and the compiler optimizations
+slow down the build process and need more disk space.
+
+? Installation and configuration issues
+
+??	Can I replace the libc on my Linux system with GNU libc?
+
+{UD} You cannot replace any existing libc for Linux with GNU
+libc.  It is binary incompatible and therefore has a different major
+version.  You can, however, install it alongside your existing libc.
+
+For Linux there are three major libc versions:
+	libc-4		a.out libc
+	libc-5		original ELF libc
+	libc-6		GNU libc
+
+You can have any combination of these three installed.  For more
+information consult documentation for shared library handling.  The
+Makefiles of GNU libc will automatically generate the needed symbolic
+links which the linker will use.
+
+??	How do I configure GNU libc so that the essential libraries
+	like libc.so go into /lib and the other into /usr/lib?
+
+{UD,AJ} Like all other GNU packages GNU libc is designed to use a base
+directory and install all files relative to this.  The default is
+/usr/local, because this is safe (it will not damage the system if
+installed there).  If you wish to install GNU libc as the primary C
+library on your system, set the base directory to /usr (i.e. run
+configure --prefix=/usr <other_options>).  Note that this can damage
+your system; see ?safety for details.
+
+Some systems like Linux have a filesystem standard which makes a
+difference between essential libraries and others.  Essential
+libraries are placed in /lib because this directory is required to be
+located on the same disk partition as /.  The /usr subtree might be
+found on another partition/disk. If you configure for Linux with
+--prefix=/usr, then this will be done automatically.
+
+To install the essential libraries which come with GNU libc in /lib on
+systems other than Linux one must explicitly request it.  Autoconf has
+no option for this so you have to use a `configparms' file (see the
+`INSTALL' file for details).  It should contain:
+
+slibdir=/lib
+sysconfdir=/etc
+
+The first line specifies the directory for the essential libraries,
+the second line the directory for system configuration files.
+
+??safety	How should I avoid damaging my system when I install GNU libc?
+
+{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.)
+
+The dangers when installing glibc in /usr are twofold:
+
+* glibc will overwrite the headers in /usr/include.  Other C libraries
+  install a different but overlapping set of headers there, so the
+  effect will probably be that you can't compile anything.  You need to
+  rename /usr/include out of the way first.  (Do not throw it away; you
+  will then lose the ability to compile programs against your old libc.)
+
+* None of your old libraries, static or shared, can be used with a
+  different C library major version.  For shared libraries this is not a
+  problem, because the filenames are different and the dynamic linker
+  will enforce the restriction.  But static libraries have no version
+  information.  You have to evacuate all the static libraries in
+  /usr/lib to a safe location.
+
+The situation is rather similar to the move from a.out to ELF which
+long-time Linux users will remember.
+
+??	Do I need to use GNU CC to compile programs that will use the
+	GNU C Library?
+
+{ZW} In theory, no; the linker does not care, and the headers are
+supposed to check for GNU CC before using its extensions to the C
+language.
+
+However, there are currently no ports of glibc to systems where
+another compiler is the default, so no one has tested the headers
+extensively against another compiler.  You may therefore encounter
+difficulties.  If you do, please report them as bugs.
+
+Also, in several places GNU extensions provide large benefits in code
+quality.  For example, the library has hand-optimized, inline assembly
+versions of some string functions.  These can only be used with GCC.
+See ?string for details.
+
+??crypt	When linking with the new libc I get unresolved symbols
+	`crypt' and `setkey'.  Why aren't these functions in the
+	libc anymore?
+
+{UD} The US places restrictions on exporting cryptographic programs
+and source code.  Until this law gets abolished we cannot ship the
+cryptographic functions together with glibc.
+
+The functions are available, as an add-on (see ?addon).  People in the
+US may get it from the same place they got GNU libc from.  People
+outside the US should get the code from ftp://ftp.ifi.uio.no/pub/gnu,
+or another archive site outside the USA.  The README explains how to
+install the sources.
+
+If you already have the crypt code on your system the reason for the
+failure is probably that you did not link with -lcrypt.  The crypto
+functions are in a separate library to make it possible to export GNU
+libc binaries from the US.
+
+??	When I use GNU libc on my Linux system by linking against
+	the libc.so which comes with glibc all I get is a core dump.
+
+{UD} On Linux, gcc sets the dynamic linker to /lib/ld-linux.so.1
+unless the user specifies a -dynamic-linker argument.  This is the
+name of the libc5 dynamic linker, which does not work with glibc.
+
+For casual use of GNU libc you can just specify
+    -dynamic-linker=/lib/ld-linux.so.2
+
+which is the glibc dynamic linker, on Linux systems.  On other systems
+the name is /lib/ld.so.1.
+
+To change your environment to use GNU libc for compiling you need to
+change the `specs' file of your gcc.  This file is normally found at
+
+	/usr/lib/gcc-lib/<arch>/<version>/specs
+
+In this file you have to change a few things:
+
+- change `ld-linux.so.1' to `ld-linux.so.2'
+
+- remove all expression `%{...:-lgmon}';  there is no libgmon in glibc
+
+- fix a minor bug by changing %{pipe:-} to %|
+
+Here is what the gcc-2.7.2 specs file should look like when GNU libc
+is installed at /usr:
+
+-----------------------------------------------------------------------
+*asm:
+%{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
+
+*asm_final:
+%|
+
+*cpp:
+%{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
+
+*cc1:
+%{profile:-p}
+
+*cc1plus:
+
+
+*endfile:
+%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s
+
+*link:
+-m elf_i386 %{shared:-shared}   %{!shared:     %{!ibcs:       %{!static: 	%{rdynamic:-export-dynamic} 	%{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}} 	%{static:-static}}}
+
+*lib:
+%{!shared: %{pthread:-lpthread} 	%{profile:-lc_p} %{!profile: -lc}}
+
+*libgcc:
+-lgcc
+
+*startfile:
+%{!shared:      %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} 		     %{!p:%{profile:gcrt1.o%s} 			 %{!profile:crt1.o%s}}}}    crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}
+
+*switches_need_spaces:
+
+
+*signed_char:
+%{funsigned-char:-D__CHAR_UNSIGNED__}
+
+*predefines:
+-D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386)
+
+*cross_compile:
+0
+
+*multilib:
+. ;
+
+-----------------------------------------------------------------------
+
+Things get a bit more complicated if you have GNU libc installed in
+some other place than /usr, i.e., if you do not want to use it instead
+of the old libc.  In this case the needed startup files and libraries
+are not found in the regular places.  So the specs file must tell the
+compiler and linker exactly what to use.
+
+Version 2.7.2.3 does and future versions of GCC will automatically
+provide the correct specs.
+
+??	Looking through the shared libc file I haven't found the
+	functions `stat', `lstat', `fstat', and `mknod' and while
+	linking on my Linux system I get error messages.  How is
+	this supposed to work?
+
+{RM} Believe it or not, stat and lstat (and fstat, and mknod)
+are supposed to be undefined references in libc.so.6!  Your problem is
+probably a missing or incorrect /usr/lib/libc.so file; note that this
+is a small text file now, not a symlink to libc.so.6.  It should look
+something like this:
+
+GROUP ( libc.so.6 ld.so.1 libc.a )
+
+or in ix86/Linux and alpha/Linux:
+
+GROUP ( libc.so.6 ld-linux.so.2 libc.a )
+
+??	How can I compile gcc 2.7.2.1 from the gcc source code using
+	glibc 2.x?
+
+{AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3
+or later.  You should get at least gcc 2.7.2.3.  All previous versions
+had problems with glibc support.
+
+??	The `gencat' utility cannot process the catalog sources which
+	were used on my Linux libc5 based system.  Why?
+
+{UD} The `gencat' utility provided with glibc complies to the XPG
+standard.  The older Linux version did not obey the standard, so they
+are not compatible.
+
+To ease the transition from the Linux version some of the non-standard
+features are also present in the `gencat' program of GNU libc.  This
+mainly includes the use of symbols for the message number and the automatic
+generation of header files which contain the needed #defines to map the
+symbols to integers.
+
+Here is a simple SED script to convert at least some Linux specific
+catalog files to the XPG4 form:
+
+-----------------------------------------------------------------------
+# Change catalog source in Linux specific format to standard XPG format.
+# Ulrich Drepper <drepper@cygnus.com>, 1996.
+#
+/^\$ #/ {
+  h
+  s/\$ #\([^ ]*\).*/\1/
+  x
+  s/\$ #[^ ]* *\(.*\)/\$ \1/
+}
+
+/^# / {
+  s/^# \(.*\)/\1/
+  G
+  s/\(.*\)\n\(.*\)/\2 \1/
+}
+-----------------------------------------------------------------------
+
+??	I have set up /etc/nis.conf, and the Linux libc 5 with NYS
+	works great.  But the glibc NIS+ doesn't seem to work.
+
+{??} The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START
+file for storing information about the NIS+ server and their public
+keys, because the nis.conf file does not contain all the necessary
+information.  You have to copy a NIS_COLD_START file from a Solaris
+client (the NIS_COLD_START file is byte order independent) or generate
+it with nisinit from the nis-tools package (available at
+http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html).
+
+??	After installing glibc name resolving doesn't work properly.
+
+{AJ} You probably should read the manual section describing
+nsswitch.conf (just type `info libc "NSS Configuration File"').
+The NSS configuration file is usually the culprit.
+
+??	I have /usr/include/net and /usr/include/scsi as symlinks
+	into my Linux source tree.  Is that wrong?
+
+{PB} This was necessary for libc5, but is not correct when using
+glibc.  Including the kernel header files directly in user programs
+usually does not work (see ?kerhdr).  glibc provides its own <net/*>
+and <scsi/*> header files to replace them, and you may have to remove
+any symlink that you have in place before you install glibc.  However,
+/usr/include/asm and /usr/include/linux should remain as they were.
+
+??	Programs like `logname', `top', `uptime' `users', `w' and
+	`who', show incorrect information about the (number of)
+	users on my system.  Why?
+
+{MK} See ?getlog.
+
+??	After upgrading to glibc 2.1 with symbol versioning I get
+	errors about undefined symbols.  What went wrong?
+
+{AJ} The problem is caused either by wrong program code or tools.  In
+the versioned libc a lot of symbols are now local that were global
+symbols in previous versions.  It seems that programs linked against
+older versions often accidentally used libc global variables --
+something that should not happen.
+
+The only way to fix this is to recompile your program. Sorry, that's
+the price you might have to pay once for quite a number of advantages
+with symbol versioning.
+
+??	When I start the program XXX after upgrading the library
+	I get
+	  XXX: Symbol `_sys_errlist' has different size in shared
+	  object, consider re-linking
+	Why?  What should I do?
+
+{UD} As the message says, relink the binary.  The problem is that
+a few symbols from the library can change in size and there is no way
+to avoid this.  _sys_errlist is a good example.  Occasionally there are
+new error numbers added to the kernel and this must be reflected at user
+level, breaking programs that refer to them directly.
+
+Such symbols should normally not be used at all.  There are mechanisms
+to avoid using them.  In the case of _sys_errlist, there is the
+strerror() function which should _always_ be used instead.  So the
+correct fix is to rewrite that part of the application.
+
+In some situations (especially when testing a new library release) it
+might be possible that a symbol changed size when that should not have
+happened.  So in case of doubt report such a warning message as a
+problem.
+
+? Source and binary incompatibilities, and what to do about them
+
+??	I expect GNU libc to be 100% source code compatible with
+	the old Linux based GNU libc.  Why isn't it like this?
+
+{DMT,UD} Not every extension in Linux libc's history was well
+thought-out.  In fact it had a lot of problems with standards compliance
+and with cleanliness.  With the introduction of a new version number these
+errors can now be corrected.  Here is a list of the known source code
+incompatibilities:
+
+* _GNU_SOURCE: glibc does not make the GNU extensions available
+  automatically.  If a program depends on GNU extensions or some
+  other non-standard functionality, it is necessary to compile it
+  with the C compiler option -D_GNU_SOURCE, or better, to put
+  `#define _GNU_SOURCE' at the beginning of your source files, before
+  any C library header files are included.  This difference normally
+  manifests itself in the form of missing prototypes and/or data type
+  definitions.  Thus, if you get such errors, the first thing you
+  should do is try defining _GNU_SOURCE and see if that makes the
+  problem go away.
+
+  For more information consult the file `NOTES' in the GNU C library
+  sources.
+
+* reboot(): GNU libc sanitizes the interface of reboot() to be more
+  compatible with the interface used on other OSes.  reboot() as
+  implemented in glibc takes just one argument.  This argument
+  corresponds to the third argument of the Linux reboot system call.
+  That is, a call of the form reboot(a, b, c) needs to be changed into
+  reboot(c).  Beside this the header <sys/reboot.h> defines the needed
+  constants for the argument.  These RB_* constants should be used
+  instead of the cryptic magic numbers.
+
+* swapon(): the interface of this function didn't change, but the
+  prototype is in a separate header file <sys/swap.h>.  This header
+  file also provides the SWAP_* constants defined by <linux/swap.h>;
+  you should use them for the second argument to swapon().
+
+* errno: If a program uses the variable "errno", then it _must_
+  include <errno.h>.  The old libc often (erroneously) declared this
+  variable implicitly as a side-effect of including other libc header
+  files.  glibc is careful to avoid such namespace pollution, which,
+  in turn, means that you really need to include the header files that
+  you depend on.  This difference normally manifests itself in the
+  form of the compiler complaining about references to an undeclared
+  symbol "errno".
+
+* Linux-specific syscalls: All Linux system calls now have appropriate
+  library wrappers and corresponding declarations in various header files.
+  This is because the syscall() macro that was traditionally used to
+  work around missing syscall wrappers are inherently non-portable and
+  error-prone.  The following table lists all the new syscall stubs,
+  the header-file declaring their interface and the system call name.
+
+       syscall name:	wrapper name:	declaring header file:
+       -------------	-------------	----------------------
+       bdflush		bdflush		<sys/kdaemon.h>
+       syslog		ksyslog_ctl	<sys/klog.h>
+
+* lpd: Older versions of lpd depend on a routine called _validuser().
+  The library does not provide this function, but instead provides
+  __ivaliduser() which has a slightly different interface.  Simply
+  upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD
+  lpd is known to be working).
+
+* resolver functions/BIND: like on many other systems the functions of
+  the resolver library are not included in libc itself.  There is a
+  separate library libresolv.  If you get undefined symbol errors for
+  symbols starting with `res_*' simply add -lresolv to your linker
+  command line.
+
+* the `signal' function's behavior corresponds to the BSD semantic and
+  not the SysV semantic as it was in libc-5.  The interface on all GNU
+  systems shall be the same and BSD is the semantic of choice.  To use
+  the SysV behavior simply use `sysv_signal', or define _XOPEN_SOURCE.
+  See ?signal for details.
+
+??getlog	Why does getlogin() always return NULL on my Linux box?
+
+{UD} The GNU C library has a format for the UTMP and WTMP file which
+differs from what your system currently has.  It was extended to
+fulfill the needs of the next years when IPv6 is introduced.  The
+record size is different and some fields have different positions.
+The files written by functions from the one library cannot be read by
+functions from the other library.  Sorry, but this is what a major
+release is for.  It's better to have a cut now than having no means to
+support the new techniques later.
+
+{MK} There is however a (partial) solution for this problem.  Please
+take a look at the file `README.utmpd'.
+
+??	Where are the DST_* constants found in <sys/time.h> on many
+	systems?
+
+{UD} These constants come from the old BSD days and are not used
+anymore (libc5 does not actually implement the handling although the
+constants are defined).
+
+Instead GNU libc contains zone database support and compatibility code
+for POSIX TZ environment variable handling.
+
+??	The prototypes for `connect', `accept', `getsockopt',
+	`setsockopt', `getsockname', `getpeername', `send',
+	`sendto', and `recvfrom' are different in GNU libc from
+	any other system I saw.  This is a bug, isn't it?
+
+{UD} No, this is no bug.  This version of GNU libc already follows the
+new Single Unix specifications (and I think the POSIX.1g draft which
+adopted the solution).  The type for a parameter describing a size is
+now `socklen_t', a new type.
+
+??kerhdr	On Linux I've got problems with the declarations in Linux
+	kernel headers.
+
+{UD,AJ} On Linux, the use of kernel headers is reduced to the minimum.
+This gives Linus the ability to change the headers more freely.  Also,
+user programs are now insulated from changes in the size of kernel
+data structures.
+
+For example, the sigset_t type is 32 or 64 bits wide in the kernel.
+In glibc it is 1024 bits wide.  This guarantees that when the kernel
+gets a bigger sigset_t (for POSIX.1e realtime support, say) user
+programs will not have to be recompiled.  Consult the header files for
+more information about the changes.
+
+Therefore you shouldn't include Linux kernel header files directly if
+glibc has defined a replacement. Otherwise you might get undefined
+results because of type conflicts.
+
+??	I don't include any kernel headers myself but the compiler
+	still complains about redeclarations of types in the kernel
+	headers.
+
+{UD} The kernel headers before Linux 2.1.61 don't work correctly with
+glibc.  Compiling C programs is possible in most cases but C++
+programs have (due to the change of the name lookups for `struct's)
+problems.  One prominent example is `struct fd_set'.
+
+There might be some problems left but 2.1.61 fixes most of the known
+ones.  See the BUGS file for other known problems.
+
+??signal	Why don't signals interrupt system calls anymore?
+
+{ZW} By default GNU libc uses the BSD semantics for signal(),
+unlike Linux libc 5 which used System V semantics.  This is partially
+for compatibility with other systems and partially because the BSD
+semantics tend to make programming with signals easier.
+
+There are three differences:
+
+* BSD-style signals that occur in the middle of a system call do not
+  affect the system call; System V signals cause the system call to
+  fail and set errno to EINTR.
+
+* BSD signal handlers remain installed once triggered.  System V signal
+  handlers work only once, so one must reinstall them each time.
+
+* A BSD signal is blocked during the execution of its handler.  In other
+  words, a handler for SIGCHLD (for example) does not need to worry about
+  being interrupted by another SIGCHLD.  It may, however, be interrupted
+  by other signals.
+
+There is general consensus that for `casual' programming with signals, the
+BSD semantics are preferable.  You don't need to worry about system calls
+returning EINTR, and you don't need to worry about the race conditions
+associated with one-shot signal handlers.
+
+If you are porting an old program that relies on the old semantics, you can
+quickly fix the problem by changing signal() to sysv_signal() throughout.
+Alternatively, define _XOPEN_SOURCE before including <signal.h>.
+
+For new programs, the sigaction() function allows you to specify precisely
+how you want your signals to behave.  All three differences listed above are
+individually switchable on a per-signal basis with this function.
+
+If all you want is for one specific signal to cause system calls to fail
+and return EINTR (for example, to implement a timeout) you can do this with
+siginterrupt().
+
+
+??string	I've got errors compiling code that uses certain string
+	functions.  Why?
+
+{AJ} glibc 2.1 has special string functions that are faster
+than the normal library functions. Some of the functions are
+implemented as inline functions and others as macros.
+
+The optimized string functions are only used when compiling with
+optimizations (-O1 or higher). The behavior can be changed with two
+feature macros:
+
+* __NO_STRING_INLINES: Don't do any string optimizations.
+* __USE_STRING_INLINES: Use assembly language inline functions (might
+  increase code size dramatically).
+
+Since some of these string functions are now additionally defined as
+macros, code like "char *strncpy();" doesn't work anymore (and is
+unnecessary, since <string.h> has the necessary declarations). Either
+change your code or define __NO_STRING_INLINES.
+
+{UD} Another problem in this area is that gcc still has problems on
+machines with very few registers (e.g., ix86).  The inline assembler
+code can require almost all the registers and the register allocator
+cannot always handle this situation.
+
+One can disable the string optimizations selectively.  Instead of writing
+
+	cp = strcpy (foo, "lkj");
+
+one can write
+
+	cp = (strcpy) (foo, "lkj");
+
+This disables the optimization for that specific call.
+
+? Miscellaneous
+
+??	After I changed configure.in I get `Autoconf version X.Y.
+	or higher is required for this script'.  What can I do?
+
+{UD} You have to get the specified autoconf version (or a later one)
+from your favorite mirror of prep.ai.mit.edu.
+
+??	When I try to compile code which uses IPv6 headers and
+	definitions on my Linux 2.x.y system I am in trouble.
+	Nothing seems to work.
+
+{UD} The problem is that IPv6 development still has not reached a
+point where the headers are stable.  There are still lots of
+incompatible changes made and the libc headers have to follow.
+
+Also, make sure you have a suitably recent kernel.  As of the 970401
+snapshot, according to Philip Blundell <philb@gnu.ai.mit.edu>, the
+required kernel version is 2.1.30.
+
+
+Answers were given by:
+{UD} Ulrich Drepper, <drepper@cygnus.com>
+{DMT} David Mosberger-Tang, <davidm@AZStarNet.com>
+{RM} Roland McGrath, <roland@gnu.org>
+{AJ} Andreas Jaeger, <aj@arthur.rhein-neckar.de>
+{EY} Eric Youngdale, <eric@andante.jic.com>
+{PB} Phil Blundell, <Philip.Blundell@pobox.com>
+{MK} Mark Kettenis, <kettenis@phys.uva.nl>
+{ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu>
+
+Local Variables:
+ mode:outline
+ outline-regexp:"\\?"
+End: