-Library Maintenance
-*******************
-
-How to Install the GNU C Library
-================================
-
- Installation of the GNU C library is relatively simple, but usually
-requires several GNU tools to be installed already.
-
- To configure the GNU C library for your system, run the shell script
-`configure' with `sh'. Use an argument which is the conventional GNU
-name for your system configuration--for example, `sparc-sun-sunos4.1',
-for a Sun 4 running SunOS 4.1. *Note Installation:
-(gcc.info)Installation, for a full description of standard GNU
-configuration names. If you omit the configuration name, `configure'
-will try to guess one for you by inspecting the system it is running
-on. It may or may not be able to come up with a guess, and the its
-guess might be wrong. `configure' will tell you the canonical name of
-the chosen configuration before proceeding.
-
- Here are some options that you should specify (if appropriate) when
-you run `configure':
-
-`--with-gnu-ld'
- Use this option if you plan to use GNU `ld' to link programs with
- the GNU C Library. (We strongly recommend that you do.) This
- option enables use of features that exist only in GNU `ld'; so if
- you configure for GNU `ld' you must use GNU `ld' *every time* you
- link with the GNU C Library, and when building it.
-
-`--with-gnu-as'
- Use this option if you plan to use the GNU assembler, `gas', when
- building the GNU C Library. On some systems, the library may not
- build properly if you do *not* use `gas'.
-
-`--with-gnu-binutils'
- This option implies both `--with-gnu-ld' and `--with-gnu-as'. On
- systems where GNU tools are the system tools, there is no need to
- specify this option. These include GNU, GNU/Linux, and free BSD
- systems.
+Installing the GNU C Library
+****************************
-`--without-fp'
-`--nfp'
- Use this option if your computer lacks hardware floating-point
- support.
+Before you do anything else, you should read the FAQ at
+`http://sourceware.org/glibc/wiki/FAQ'. It answers common questions
+and describes problems you may experience with compilation and
+installation.
+
+ Features can be added to the GNU C Library via "add-on" bundles.
+These are separate tar files, which you unpack into the top level of
+the source tree. Then you give `configure' the `--enable-add-ons'
+option to activate them, and they will be compiled into the library.
+
+ You will need recent versions of several GNU tools: definitely GCC
+and GNU Make, and possibly others. *Note Tools for Compilation::,
+below.
+
+Configuring and compiling the GNU C Library
+===========================================
+
+The GNU C Library cannot be compiled in the source directory. You must
+build it in a separate build directory. For example, if you have
+unpacked the GNU C Library sources in `/src/gnu/glibc-VERSION', create
+a directory `/src/gnu/glibc-build' to put the object files in. This
+allows removing the whole build directory in case an error occurs,
+which is the safest way to get a fresh start and should always be done.
+
+ From your object directory, run the shell script `configure' located
+at the top level of the source tree. In the scenario above, you'd type
+
+ $ ../glibc-VERSION/configure ARGS...
+
+ Please note that even though you're building in a separate build
+directory, the compilation may need to create or modify files and
+directories in the source directory.
+
+`configure' takes many options, but the only one that is usually
+mandatory is `--prefix'. This option tells `configure' where you want
+the GNU C Library installed. This defaults to `/usr/local', but the
+normal setting to install as the standard system library is
+`--prefix=/usr' for GNU/Linux systems and `--prefix=' (an empty prefix)
+for GNU/Hurd systems.
+
+ It may also be useful to set the CC and CFLAGS variables in the
+environment when running `configure'. CC selects the C compiler that
+will be used, and CFLAGS sets optimization options for the compiler.
+
+ The following list describes all of the available options for
+`configure':
`--prefix=DIRECTORY'
Install machine-independent data files in subdirectories of
- `DIRECTORY'. (You can also set this in `configparms'; see below.)
+ `DIRECTORY'. The default is to install in `/usr/local'.
`--exec-prefix=DIRECTORY'
Install the library and other machine-dependent files in
- subdirectories of `DIRECTORY'. (You can also set this in
- `configparms'; see below.)
+ subdirectories of `DIRECTORY'. The default is to the `--prefix'
+ directory if that option is specified, or `/usr/local' otherwise.
+
+`--with-headers=DIRECTORY'
+ Look for kernel header files in DIRECTORY, not `/usr/include'.
+ The GNU C Library needs information from the kernel's header files
+ describing the interface to the kernel. The GNU C Library will
+ normally look in `/usr/include' for them, but if you specify this
+ option, it will look in DIRECTORY instead.
+
+ This option is primarily of use on a system where the headers in
+ `/usr/include' come from an older version of the GNU C Library.
+ Conflicts can occasionally happen in this case. You can also use
+ this option if you want to compile the GNU C Library with a newer
+ set of kernel headers than the ones found in `/usr/include'.
+
+`--enable-add-ons[=LIST]'
+ Specify add-on packages to include in the build. If this option is
+ specified with no list, it enables all the add-on packages it
+ finds in the main source directory; this is the default behavior.
+ You may specify an explicit list of add-ons to use in LIST,
+ separated by spaces or commas (if you use spaces, remember to
+ quote them from the shell). Each add-on in LIST can be an
+ absolute directory name or can be a directory name relative to the
+ main source directory, or relative to the build directory (that
+ is, the current working directory). For example,
+ `--enable-add-ons=nptl,../glibc-libidn-VERSION'.
+
+`--enable-kernel=VERSION'
+ This option is currently only useful on GNU/Linux systems. The
+ VERSION parameter should have the form X.Y.Z and describes the
+ smallest version of the Linux kernel the generated library is
+ expected to support. The higher the VERSION number is, the less
+ compatibility code is added, and the faster the code gets.
+
+`--with-binutils=DIRECTORY'
+ Use the binutils (assembler and linker) in `DIRECTORY', not the
+ ones the C compiler would default to. You can use this option if
+ the default binutils on your system cannot deal with all the
+ constructs in the GNU C Library. In that case, `configure' will
+ detect the problem and suppress these constructs, so that the
+ library will still be usable, but functionality may be lost--for
+ example, you can't build a shared libc with old binutils.
+
+`--without-fp'
+ Use this option if your computer lacks hardware floating-point
+ support and your operating system does not emulate an FPU.
-`--enable-shared'
`--disable-shared'
- Enable or disable building of an ELF shared library on systems that
- support it. The default is to build the shared library on systems
- using ELF when the GNU `binutils' are available.
+ Don't build shared libraries even if it is possible. Not all
+ systems support shared libraries; you need ELF support and
+ (currently) the GNU linker.
-`--enable-profile'
`--disable-profile'
- Enable or disable building of the profiled C library, `-lc_p'. The
- default is to build the profiled library. You may wish to disable
- it if you don't plan to do profiling, because it doubles the build
- time of compiling just the unprofiled static library.
-
-`--enable-omitfp'
- Enable building a highly-optimized but possibly undebuggable
- static C library. This causes the normal static and shared (if
- enabled) C libraries to be compiled with maximal optimization,
- including the `-fomit-frame-pointer' switch that makes debugging
- impossible on many machines, and without debugging information
- (which makes the binaries substantially smaller). An additional
- static library is compiled with no optimization and full debugging
- information, and installed as `-lc_g'.
-
-`--enable-bounded'
-`--disable-bounded'
- Enable or disable building of the C library with support for bounded
- pointers. To do this one need the enhanced version of the GNU CC
- with can generate code for bounded pointers. This version of the
- C library is necessary to run code which is also compiled using the
- enhanced gcc for debugging purposes.
-
-There are two more options:
-
-`--with-gmp'
-`--with-gettext'
- These options are not of much use for the normal installer of the
- GNU libc. Only maintainers need this to get automatic updates of
- the files from these packages in the GNU C library source tree.
-
-
- The simplest way to run `configure' is to do it in the directory
-that contains the library sources. This prepares to build the library
-in that very directory.
-
- You can prepare to build the library in some other directory by going
-to that other directory to run `configure'. In order to run configure,
-you will have to specify a directory for it, like this:
-
- mkdir sun4
- cd sun4
- ../configure sparc-sun-sunos4.1
-
-`configure' looks for the sources in whatever directory you specified
-for finding `configure' itself. It does not matter where in the file
-system the source and build directories are--as long as you specify the
-source directory when you run `configure', you will get the proper
-results.
-
- This feature lets you keep sources and binaries in different
-directories, and that makes it easy to build the library for several
-different machines from the same set of sources. Simply create a build
-directory for each target machine, and run `configure' in that
-directory specifying the target machine's configuration name.
-
- The library has a number of special-purpose configuration parameters.
-These are defined in the file `Makeconfig'; see the comments in that
-file for the details.
-
- But don't edit the file `Makeconfig' yourself--instead, create a
-file `configparms' in the directory where you are building the library,
-and define in that file the parameters you want to specify.
-`configparms' should *not* be an edited copy of `Makeconfig'; specify
-only the parameters that you want to override. To see how to set these
-parameters, find the section of `Makeconfig' that says "These are the
-configuration variables." Then for each parameter that you want to
-change, copy the definition from `Makeconfig' to your new `configparms'
-file, and change the value as appropriate for your system.
-
- It is easy to configure the GNU C library for cross-compilation by
-setting a few variables in `configparms'. Set `CC' to the
-cross-compiler for the target you configured the library for; it is
-important to use this same `CC' value when running `configure', like
-this: `CC=TARGET-gcc configure TARGET'. Set `BUILD_CC' to the compiler
-to use for for programs run on the build system as part of compiling
-the library. You may need to set `AR' and `RANLIB' to cross-compiling
-versions of `ar' and `ranlib' if the native tools are not configured to
-work with object files for the target you configured for.
-
- Some of the machine-dependent code for some machines uses extensions
-in the GNU C compiler, so you may need to compile the library with GCC.
-(In fact, all of the existing complete ports require GCC.)
+ Don't build libraries with profiling information. You may want to
+ use this option if you don't plan to do profiling.
+
+`--disable-versioning'
+ Don't compile the shared libraries with symbol version information.
+ Doing this will make the resulting library incompatible with old
+ binaries, so it's not recommended.
+
+`--enable-static-nss'
+ Compile static versions of the NSS (Name Service Switch) libraries.
+ This is not recommended because it defeats the purpose of NSS; a
+ program linked statically with the NSS libraries cannot be
+ dynamically reconfigured to use a different name database.
+
+`--without-tls'
+ By default the C library is built with support for thread-local
+ storage if the used tools support it. By using `--without-tls'
+ this can be prevented though there generally is no reason since it
+ creates compatibility problems.
+
+`--enable-hardcoded-path-in-tests'
+ By default, dynamic tests are linked to run with the installed C
+ library. This option hardcodes the newly built C library path in
+ dynamic tests so that they can be invoked directly.
+
+`--enable-lock-elision=yes'
+ Enable lock elision for pthread mutexes and rwlocks by default.
+
+`--build=BUILD-SYSTEM'
+`--host=HOST-SYSTEM'
+ These options are for cross-compiling. If you specify both
+ options and BUILD-SYSTEM is different from HOST-SYSTEM, `configure'
+ will prepare to cross-compile the GNU C Library from BUILD-SYSTEM
+ to be used on HOST-SYSTEM. You'll probably need the
+ `--with-headers' option too, and you may have to override
+ CONFIGURE's selection of the compiler and/or binutils.
+
+ If you only specify `--host', `configure' will prepare for a
+ native compile but use what you specify instead of guessing what
+ your system is. This is most useful to change the CPU submodel.
+ For example, if `configure' guesses your machine as
+ `i686-pc-linux-gnu' but you want to compile a library for 586es,
+ give `--host=i586-pc-linux-gnu' or just `--host=i586-linux' and add
+ the appropriate compiler flags (`-mcpu=i586' will do the trick) to
+ CFLAGS.
+
+ If you specify just `--build', `configure' will get confused.
+
+`--with-pkgversion=VERSION'
+ Specify a description, possibly including a build number or build
+ date, of the binaries being built, to be included in `--version'
+ output from programs installed with the GNU C Library. For
+ example, `--with-pkgversion='FooBar GNU/Linux glibc build 123''.
+ The default value is `GNU libc'.
+
+`--with-bugurl=URL'
+ Specify the URL that users should visit if they wish to report a
+ bug, to be included in `--help' output from programs installed with
+ the GNU C Library. The default value refers to the main
+ bug-reporting information for the GNU C Library.
To build the library and related programs, type `make'. This will
produce a lot of output, some of which may look like errors from `make'
-(but isn't). Look for error messages from `make' containing `***'.
-Those indicate that something is really wrong.
-
- To build and run some test programs which exercise some of the
-library facilities, type `make check'. This will produce several files
-with names like `PROGRAM.out'.
+but isn't. Look for error messages from `make' containing `***'.
+Those indicate that something is seriously wrong.
+
+ The compilation process can take a long time, depending on the
+configuration and the speed of your machine. Some complex modules may
+take a very long time to compile, as much as several minutes on slower
+machines. Do not panic if the compiler appears to hang.
+
+ If you want to run a parallel make, simply pass the `-j' option with
+an appropriate numeric parameter to `make'. You need a recent GNU
+`make' version, though.
+
+ To build and run test programs which exercise some of the library
+facilities, type `make check'. If it does not complete successfully,
+do not use the built library, and report a bug after verifying that the
+problem is not already known. *Note Reporting Bugs::, for instructions
+on reporting bugs. Note that some of the tests assume they are not
+being run by `root'. We recommend you compile and test the GNU C
+Library as an unprivileged user.
+
+ Before reporting bugs make sure there is no problem with your system.
+The tests (and later installation) use some pre-existing files of the
+system such as `/etc/passwd', `/etc/nsswitch.conf' and others. These
+files must all contain correct and sensible content.
To format the `GNU C Library Reference Manual' for printing, type
-`make dvi'.
-
- To install the library and its header files, and the Info files of
-the manual, type `make install'. This will build things if necessary,
-before installing them.
-
-Recommended Tools to Install the GNU C Library
-----------------------------------------------
+`make dvi'. You need a working TeX installation to do this. The
+distribution builds the on-line formatted version of the manual, as
+Info files, as part of the build process. You can build them manually
+with `make info'.
+
+ The library has a number of special-purpose configuration parameters
+which you can find in `Makeconfig'. These can be overwritten with the
+file `configparms'. To change them, create a `configparms' in your
+build directory and add values as appropriate for your system. The
+file is included and parsed by `make' and has to follow the conventions
+for makefiles.
+
+ It is easy to configure the GNU C Library for cross-compilation by
+setting a few variables in `configparms'. Set `CC' to the
+cross-compiler for the target you configured the library for; it is
+important to use this same `CC' value when running `configure', like
+this: `CC=TARGET-gcc configure TARGET'. Set `BUILD_CC' to the compiler
+to use for programs run on the build system as part of compiling the
+library. You may need to set `AR' to cross-compiling versions of `ar'
+if the native tools are not configured to work with object files for
+the target you configured for. When cross-compiling the GNU C Library,
+it may be tested using `make check
+test-wrapper="SRCDIR/scripts/cross-test-ssh.sh HOSTNAME"', where SRCDIR
+is the absolute directory name for the main source directory and
+HOSTNAME is the host name of a system that can run the newly built
+binaries of the GNU C Library. The source and build directories must
+be visible at the same locations on both the build system and HOSTNAME.
+
+ In general, when testing the GNU C Library, `test-wrapper' may be set
+to the name and arguments of any program to run newly built binaries.
+This program must preserve the arguments to the binary being run, its
+working directory, all environment variables set as part of testing and
+the standard input, output and error file descriptors. If
+`TEST-WRAPPER env' will not work to run a program with environment
+variables set, then `test-wrapper-env' must be set to a program that
+runs a newly built program with environment variable assignments in
+effect, those assignments being specified as `VAR=VALUE' before the
+name of the program to be run.
+
+Installing the C Library
+========================
+
+To install the library and its header files, and the Info files of the
+manual, type `env LANGUAGE=C LC_ALL=C make install'. This will build
+things, if necessary, before installing them; however, you should still
+compile everything first. If you are installing the GNU C Library as
+your primary C library, we recommend that you shut the system down to
+single-user mode first, and reboot afterward. This minimizes the risk
+of breaking things when the library changes out from underneath.
+
+ `make install' will do the entire job of upgrading from a previous
+installation of the GNU C Library version 2.x. There may sometimes be
+headers left behind from the previous installation, but those are
+generally harmless. If you want to avoid leaving headers behind you
+can do things in the following order.
+
+ You must first build the library (`make'), optionally check it
+(`make check'), switch the include directories and then install (`make
+install'). The steps must be done in this order. Not moving the
+directory before install will result in an unusable mixture of header
+files from both libraries, but configuring, building, and checking the
+library requires the ability to compile and run programs against the old
+library. The new `/usr/include', after switching the include
+directories and before installing the library should contain the Linux
+headers, but nothing else. If you do this, you will need to restore
+any headers from libraries other than the GNU C Library yourself after
+installing the library.
+
+ You can install the GNU C Library somewhere other than where you
+configured it to go by setting the `install_root' variable on the
+command line for `make install'. The value of this variable is
+prepended to all the paths for installation. This is useful when
+setting up a chroot environment or preparing a binary distribution.
+The directory should be specified with an absolute file name.
+
+ The GNU C Library includes a daemon called `nscd', which you may or
+may not want to run. `nscd' caches name service lookups; it can
+dramatically improve performance with NIS+, and may help with DNS as
+well.
+
+ One auxiliary program, `/usr/libexec/pt_chown', is installed setuid
+`root'. This program is invoked by the `grantpt' function; it sets the
+permissions on a pseudoterminal so it can be used by the calling
+process. This means programs like `xterm' and `screen' do not have to
+be setuid to get a pty. (There may be other reasons why they need
+privileges.) If you are using a Linux kernel with the `devptsfs' or
+`devfs' filesystems providing pty slaves, you don't need this program;
+otherwise you do. The source for `pt_chown' is in
+`login/programs/pt_chown.c'.
+
+ After installation you might want to configure the timezone and
+locale installation of your system. The GNU C Library comes with a
+locale database which gets configured with `localedef'. For example, to
+set up a German locale with name `de_DE', simply issue the command
+`localedef -i de_DE -f ISO-8859-1 de_DE'. To configure all locales
+that are supported by the GNU C Library, you can issue from your build
+directory the command `make localedata/install-locales'.
+
+ To configure the locally used timezone, set the `TZ' environment
+variable. The script `tzselect' helps you to select the right value.
+As an example, for Germany, `tzselect' would tell you to use
+`TZ='Europe/Berlin''. For a system wide installation (the given paths
+are for an installation with `--prefix=/usr'), link the timezone file
+which is in `/usr/share/zoneinfo' to the file `/etc/localtime'. For
+Germany, you might execute `ln -s /usr/share/zoneinfo/Europe/Berlin
+/etc/localtime'.
+
+Recommended Tools for Compilation
+=================================
- We recommend installing the following GNU tools before attempting to
-build the GNU C library:
+We recommend installing the following GNU tools before attempting to
+build the GNU C Library:
- * `make' 3.75
+ * GNU `make' 3.79 or newer
You need the latest version of GNU `make'. Modifying the GNU C
- Library to work with other `make' programs would be so hard that we
- recommend you port GNU `make' instead. *Really.* We recommend
- version GNU `make' version 3.75 or later.
-
- * GCC 2.7.2.1
-
- On most platforms, the GNU C library can only be compiled with the
- GNU C compiler. We recommend GCC version 2.7.2 or later; earlier
- versions may have problems.
-
- * `binutils' 2.7
-
- Using the GNU `binutils' (assembler, linker, and related tools) is
- preferable when possible, and they are required to build an ELF
- shared C library. We recommend `binutils' version 2.7 or later;
- earlier versions are known to have problems or to not support all
- architectures.
-
-Supported Configurations
-------------------------
-
- The GNU C Library currently supports configurations that match the
-following patterns:
-
- alpha-ANYTHING-linux
- alpha-ANYTHING-linuxecoff
- iX86-ANYTHING-gnu
- iX86-ANYTHING-linux
- m68k-ANYTHING-linux
- mips-ANYTHING-linux
- sparc-ANYTHING-linux
- powerpc-ANYTHING-linux
-
- Former versions of this library used to support the following
-configurations but the current status is unknown:
-
- alpha-dec-osf1
- iX86-ANYTHING-bsd4.3
- iX86-ANYTHING-isc2.2
- iX86-ANYTHING-isc3.N
- iX86-ANYTHING-sco3.2
- iX86-ANYTHING-sco3.2v4
- iX86-ANYTHING-sysv
- iX86-ANYTHING-sysv4
- iX86-force_cpu386-none
- iX86-sequent-bsd
- i960-nindy960-none
- m68k-hp-bsd4.3
- m68k-mvme135-none
- m68k-mvme136-none
- m68k-sony-newsos3
- m68k-sony-newsos4
- m68k-sun-sunos4.N
- mips-dec-ultrix4.N
- mips-sgi-irix4.N
- sparc-sun-solaris2.N
- sparc-sun-sunos4.N
-
- Each case of `iX86' can be `i386', `i486', `i586', or `i686'. All
-of those configurations produce a library that can run on any of these
-processors. The library will be optimized for the specified processor,
-but will not use instructions not available on all of them.
-
- While no other configurations are supported, there are handy aliases
-for these few. (These aliases work in other GNU software as well.)
-
- decstation
- hp320-bsd4.3 hp300bsd
- i486-gnu
- i586-linux
- i386-sco
- i386-sco3.2v4
- i386-sequent-dynix
- i386-svr4
- news
- sun3-sunos4.N sun3
- sun4-solaris2.N sun4-sunos5.N
- sun4-sunos4.N sun4
+ Library to work with other `make' programs would be so difficult
+ that we recommend you port GNU `make' instead. *Really.* We
+ recommend GNU `make' version 3.79. All earlier versions have
+ severe bugs or lack features.
-Reporting Bugs
-==============
+ * GCC 4.4 or newer, GCC 4.6 recommended
- There are probably bugs in the GNU C library. There are certainly
-errors and omissions in this manual. If you report them, they will get
-fixed. If you don't, no one will ever know about them and they will
-remain unfixed for all eternity, if not longer.
+ GCC 4.4 or higher is required; as of this writing, GCC 4.6 is the
+ compiler we advise to use to build the GNU C Library.
- To report a bug, first you must find it. Hopefully, this will be the
-hard part. Once you've found a bug, make sure it's really a bug. A
-good way to do this is to see if the GNU C library behaves the same way
-some other C library does. If so, probably you are wrong and the
-libraries are right (but not necessarily). If not, one of the libraries
-is probably wrong.
+ You can use whatever compiler you like to compile programs that use
+ the GNU C Library.
- Once you're sure you've found a bug, try to narrow it down to the
-smallest test case that reproduces the problem. In the case of a C
-library, you really only need to narrow it down to one library function
-call, if possible. This should not be too difficult.
+ Check the FAQ for any special compiler issues on particular
+ platforms.
- The final step when you have a simple test case is to report the bug.
-When reporting a bug, send your test case, the results you got, the
-results you expected, what you think the problem might be (if you've
-thought of anything), your system type, and the version of the GNU C
-library which you are using. Also include the files `config.status'
-and `config.make' which are created by running `configure'; they will
-be in whatever directory was current when you ran `configure'.
+ * GNU `binutils' 2.20 or later
- If you think you have found some way in which the GNU C library does
-not conform to the ANSI and POSIX standards (*note Standards and
-Portability::.), that is definitely a bug. Report it!
+ You must use GNU `binutils' (as and ld) to build the GNU C Library.
+ No other assembler or linker has the necessary functionality at the
+ moment.
- Send bug reports to the Internet address `bug-glibc@prep.ai.mit.edu'
-or the UUCP path `mit-eddie!prep.ai.mit.edu!bug-glibc'. If you have
-other problems with installation or use, please report those as well.
+ * GNU `texinfo' 4.5 or later
- If you are not sure how a function should behave, and this manual
-doesn't tell you, that's a bug in the manual. Report that too! If the
-function's behavior disagrees with the manual, then either the library
-or the manual has a bug, so report the disagreement. If you find any
-errors or omissions in this manual, please report them to the Internet
-address `bug-glibc-manual@prep.ai.mit.edu' or the UUCP path
-`mit-eddie!prep.ai.mit.edu!bug-glibc-manual'.
-
-Adding New Functions
-====================
-
- The process of building the library is driven by the makefiles, which
-make heavy use of special features of GNU `make'. The makefiles are
-very complex, and you probably don't want to try to understand them.
-But what they do is fairly straightforward, and only requires that you
-define a few variables in the right places.
-
- The library sources are divided into subdirectories, grouped by
-topic.
-
- The `string' subdirectory has all the string-manipulation functions,
-`math' has all the mathematical functions, etc.
-
- Each subdirectory contains a simple makefile, called `Makefile',
-which defines a few `make' variables and then includes the global
-makefile `Rules' with a line like:
-
- include ../Rules
-
-The basic variables that a subdirectory makefile defines are:
-
-`subdir'
- The name of the subdirectory, for example `stdio'. This variable
- *must* be defined.
-
-`headers'
- The names of the header files in this section of the library, such
- as `stdio.h'.
-
-`routines'
-`aux'
- The names of the modules (source files) in this section of the
- library. These should be simple names, such as `strlen' (rather
- than complete file names, such as `strlen.c'). Use `routines' for
- modules that define functions in the library, and `aux' for
- auxiliary modules containing things like data definitions. But the
- values of `routines' and `aux' are just concatenated, so there
- really is no practical difference.
-
-`tests'
- The names of test programs for this section of the library. These
- should be simple names, such as `tester' (rather than complete file
- names, such as `tester.c'). `make tests' will build and run all
- the test programs. If a test program needs input, put the test
- data in a file called `TEST-PROGRAM.input'; it will be given to
- the test program on its standard input. If a test program wants
- to be run with arguments, put the arguments (all on a single line)
- in a file called `TEST-PROGRAM.args'. Test programs should exit
- with zero status when the test passes, and nonzero status when the
- test indicates a bug in the library or error in building.
-
-`others'
- The names of "other" programs associated with this section of the
- library. These are programs which are not tests per se, but are
- other small programs included with the library. They are built by
- `make others'.
-
-`install-lib'
-`install-data'
-`install'
- Files to be installed by `make install'. Files listed in
- `install-lib' are installed in the directory specified by `libdir'
- in `configparms' or `Makeconfig' (*note Installation::.). Files
- listed in `install-data' are installed in the directory specified
- by `datadir' in `configparms' or `Makeconfig'. Files listed in
- `install' are installed in the directory specified by `bindir' in
- `configparms' or `Makeconfig'.
-
-`distribute'
- Other files from this subdirectory which should be put into a
- distribution tar file. You need not list here the makefile itself
- or the source and header files listed in the other standard
- variables. Only define `distribute' if there are files used in an
- unusual way that should go into the distribution.
-
-`generated'
- Files which are generated by `Makefile' in this subdirectory.
- These files will be removed by `make clean', and they will never
- go into a distribution.
-
-`extra-objs'
- Extra object files which are built by `Makefile' in this
- subdirectory. This should be a list of file names like `foo.o';
- the files will actually be found in whatever directory object
- files are being built in. These files will be removed by
- `make clean'. This variable is used for secondary object files
- needed to build `others' or `tests'.
-
-Porting the GNU C Library
-=========================
-
- The GNU C library is written to be easily portable to a variety of
-machines and operating systems. Machine- and operating system-dependent
-functions are well separated to make it easy to add implementations for
-new machines or operating systems. This section describes the layout of
-the library source tree and explains the mechanisms used to select
-machine-dependent code to use.
-
- All the machine-dependent and operating system-dependent files in the
-library are in the subdirectory `sysdeps' under the top-level library
-source directory. This directory contains a hierarchy of
-subdirectories (*note Hierarchy Conventions::.).
-
- Each subdirectory of `sysdeps' contains source files for a
-particular machine or operating system, or for a class of machine or
-operating system (for example, systems by a particular vendor, or all
-machines that use IEEE 754 floating-point format). A configuration
-specifies an ordered list of these subdirectories. Each subdirectory
-implicitly appends its parent directory to the list. For example,
-specifying the list `unix/bsd/vax' is equivalent to specifying the list
-`unix/bsd/vax unix/bsd unix'. A subdirectory can also specify that it
-implies other subdirectories which are not directly above it in the
-directory hierarchy. If the file `Implies' exists in a subdirectory,
-it lists other subdirectories of `sysdeps' which are appended to the
-list, appearing after the subdirectory containing the `Implies' file.
-Lines in an `Implies' file that begin with a `#' character are ignored
-as comments. For example, `unix/bsd/Implies' contains:
- # BSD has Internet-related things.
- unix/inet
-
-and `unix/Implies' contains:
- posix
-
-So the final list is `unix/bsd/vax unix/bsd unix/inet unix posix'.
-
- `sysdeps' has two "special" subdirectories, called `generic' and
-`stub'. These two are always implicitly appended to the list of
-subdirectories (in that order), so you needn't put them in an `Implies'
-file, and you should not create any subdirectories under them intended
-to be new specific categories. `generic' is for things that can be
-implemented in machine-independent C, using only other
-machine-independent functions in the C library. `stub' is for "stub"
-versions of functions which cannot be implemented on a particular
-machine or operating system. The stub functions always return an
-error, and set `errno' to `ENOSYS' (Function not implemented). *Note
-Error Reporting::.
-
- A source file is known to be system-dependent by its having a
-version in `generic' or `stub'; every generally-available function whose
-implementation is system-dependent in should have either a generic or
-stub implementation (there is no point in having both). Some rare
-functions are only useful on specific systems and aren't defined at all
-on others; these do not appear anywhere in the system-independent
-source code or makefiles (including the `generic' and `stub'
-directories), only in the system-dependent `Makefile' in the specific
-system's subdirectory.
-
- If you come across a file that is in one of the main source
-directories (`string', `stdio', etc.), and you want to write a machine-
-or operating system-dependent version of it, move the file into
-`sysdeps/generic' and write your new implementation in the appropriate
-system-specific subdirectory. Note that if a file is to be
-system-dependent, it *must not* appear in one of the main source
-directories.
-
- There are a few special files that may exist in each subdirectory of
-`sysdeps':
-
-`Makefile'
- A makefile for this machine or operating system, or class of
- machine or operating system. This file is included by the library
- makefile `Makerules', which is used by the top-level makefile and
- the subdirectory makefiles. It can change the variables set in the
- including makefile or add new rules. It can use GNU `make'
- conditional directives based on the variable `subdir' (see above)
- to select different sets of variables and rules for different
- sections of the library. It can also set the `make' variable
- `sysdep-routines', to specify extra modules to be included in the
- library. You should use `sysdep-routines' rather than adding
- modules to `routines' because the latter is used in determining
- what to distribute for each subdirectory of the main source tree.
-
- Each makefile in a subdirectory in the ordered list of
- subdirectories to be searched is included in order. Since several
- system-dependent makefiles may be included, each should append to
- `sysdep-routines' rather than simply setting it:
-
- sysdep-routines := $(sysdep-routines) foo bar
-
-`Subdirs'
- This file contains the names of new whole subdirectories under the
- top-level library source tree that should be included for this
- system. These subdirectories are treated just like the
- system-independent subdirectories in the library source tree, such
- as `stdio' and `math'.
-
- Use this when there are completely new sets of functions and header
- files that should go into the library for the system this
- subdirectory of `sysdeps' implements. For example,
- `sysdeps/unix/inet/Subdirs' contains `inet'; the `inet' directory
- contains various network-oriented operations which only make sense
- to put in the library on systems that support the Internet.
-
-`Dist'
- This file contains the names of files (relative to the
- subdirectory of `sysdeps' in which it appears) which should be
- included in the distribution. List any new files used by rules in
- the `Makefile' in the same directory, or header files used by the
- source files in that directory. You don't need to list files that
- are implementations (either C or assembly source) of routines
- whose names are given in the machine-independent makefiles in the
- main source tree.
-
-`configure'
- This file is a shell script fragment to be run at configuration
- time. The top-level `configure' script uses the shell `.' command
- to read the `configure' file in each system-dependent directory
- chosen, in order. The `configure' files are often generated from
- `configure.in' files using Autoconf.
-
- A system-dependent `configure' script will usually add things to
- the shell variables `DEFS' and `config_vars'; see the top-level
- `configure' script for details. The script can check for
- `--with-PACKAGE' options that were passed to the top-level
- `configure'. For an option `--with-PACKAGE=VALUE' `configure'
- sets the shell variable `with_PACKAGE' (with any dashes in PACKAGE
- converted to underscores) to VALUE; if the option is just
- `--with-PACKAGE' (no argument), then it sets `with_PACKAGE' to
- `yes'.
-
-`configure.in'
- This file is an Autoconf input fragment to be processed into the
- file `configure' in this subdirectory. *Note Introduction:
- (autoconf.info)Introduction, for a description of Autoconf. You
- should write either `configure' or `configure.in', but not both.
- The first line of `configure.in' should invoke the `m4' macro
- `GLIBC_PROVIDES'. This macro does several `AC_PROVIDE' calls for
- Autoconf macros which are used by the top-level `configure'
- script; without this, those macros might be invoked again
- unnecessarily by Autoconf.
-
- That is the general system for how system-dependencies are isolated.
-
-Layout of the `sysdeps' Directory Hierarchy
--------------------------------------------
-
- A GNU configuration name has three parts: the CPU type, the
-manufacturer's name, and the operating system. `configure' uses these
-to pick the list of system-dependent directories to look for. If the
-`--nfp' option is *not* passed to `configure', the directory
-`MACHINE/fpu' is also used. The operating system often has a "base
-operating system"; for example, if the operating system is `sunos4.1',
-the base operating system is `unix/bsd'. The algorithm used to pick
-the list of directories is simple: `configure' makes a list of the base
-operating system, manufacturer, CPU type, and operating system, in that
-order. It then concatenates all these together with slashes in
-between, to produce a directory name; for example, the configuration
-`sparc-sun-sunos4.1' results in `unix/bsd/sun/sparc/sunos4.1'.
-`configure' then tries removing each element of the list in turn, so
-`unix/bsd/sparc' and `sun/sparc' are also tried, among others. Since
-the precise version number of the operating system is often not
-important, and it would be very inconvenient, for example, to have
-identical `sunos4.1.1' and `sunos4.1.2' directories, `configure' tries
-successively less specific operating system names by removing trailing
-suffixes starting with a period.
-
- As an example, here is the complete list of directories that would be
-tried for the configuration `sparc-sun-sunos4.1' (without the `--nfp'
-option):
-
- sparc/fpu
- unix/bsd/sun/sunos4.1/sparc
- unix/bsd/sun/sunos4.1
- unix/bsd/sun/sunos4/sparc
- unix/bsd/sun/sunos4
- unix/bsd/sun/sunos/sparc
- unix/bsd/sun/sunos
- unix/bsd/sun/sparc
- unix/bsd/sun
- unix/bsd/sunos4.1/sparc
- unix/bsd/sunos4.1
- unix/bsd/sunos4/sparc
- unix/bsd/sunos4
- unix/bsd/sunos/sparc
- unix/bsd/sunos
- unix/bsd/sparc
- unix/bsd
- unix/sun/sunos4.1/sparc
- unix/sun/sunos4.1
- unix/sun/sunos4/sparc
- unix/sun/sunos4
- unix/sun/sunos/sparc
- unix/sun/sunos
- unix/sun/sparc
- unix/sun
- unix/sunos4.1/sparc
- unix/sunos4.1
- unix/sunos4/sparc
- unix/sunos4
- unix/sunos/sparc
- unix/sunos
- unix/sparc
- unix
- sun/sunos4.1/sparc
- sun/sunos4.1
- sun/sunos4/sparc
- sun/sunos4
- sun/sunos/sparc
- sun/sunos
- sun/sparc
- sun
- sunos4.1/sparc
- sunos4.1
- sunos4/sparc
- sunos4
- sunos/sparc
- sunos
- sparc
-
- Different machine architectures are conventionally subdirectories at
-the top level of the `sysdeps' directory tree. For example,
-`sysdeps/sparc' and `sysdeps/m68k'. These contain files specific to
-those machine architectures, but not specific to any particular
-operating system. There might be subdirectories for specializations of
-those architectures, such as `sysdeps/m68k/68020'. Code which is
-specific to the floating-point coprocessor used with a particular
-machine should go in `sysdeps/MACHINE/fpu'.
-
- There are a few directories at the top level of the `sysdeps'
-hierarchy that are not for particular machine architectures.
-
-`generic'
-`stub'
- As described above (*note Porting::.), these are the two
- subdirectories that every configuration implicitly uses after all
- others.
-
-`ieee754'
- This directory is for code using the IEEE 754 floating-point
- format, where the C type `float' is IEEE 754 single-precision
- format, and `double' is IEEE 754 double-precision format. Usually
- this directory is referred to in the `Implies' file in a machine
- architecture-specific directory, such as `m68k/Implies'.
-
-`posix'
- This directory contains implementations of things in the library in
- terms of POSIX.1 functions. This includes some of the POSIX.1
- functions themselves. Of course, POSIX.1 cannot be completely
- implemented in terms of itself, so a configuration using just
- `posix' cannot be complete.
-
-`unix'
- This is the directory for Unix-like things. *Note Porting to
- Unix::. `unix' implies `posix'. There are some special-purpose
- subdirectories of `unix':
-
- `unix/common'
- This directory is for things common to both BSD and System V
- release 4. Both `unix/bsd' and `unix/sysv/sysv4' imply
- `unix/common'.
-
- `unix/inet'
- This directory is for `socket' and related functions on Unix
- systems. The `inet' top-level subdirectory is enabled by
- `unix/inet/Subdirs'. `unix/common' implies `unix/inet'.
-
-`mach'
- This is the directory for things based on the Mach microkernel
- from CMU (including the GNU operating system). Other basic
- operating systems (VMS, for example) would have their own
- directories at the top level of the `sysdeps' hierarchy, parallel
- to `unix' and `mach'.
-
-Porting the GNU C Library to Unix Systems
------------------------------------------
-
- Most Unix systems are fundamentally very similar. There are
-variations between different machines, and variations in what
-facilities are provided by the kernel. But the interface to the
-operating system facilities is, for the most part, pretty uniform and
-simple.
-
- The code for Unix systems is in the directory `unix', at the top
-level of the `sysdeps' hierarchy. This directory contains
-subdirectories (and subdirectory trees) for various Unix variants.
-
- The functions which are system calls in most Unix systems are
-automatically generated from the `syscalls.list' files for the appropriate
-archirecture. The format of the syscalls.list files is quite easy: only
-a few informations are necessary line the system call name, the number of
-arguments and such. The files are run through the C preprocessor.
-
- These files all use a set of macros that should be defined in
-`sysdep.h'. The `sysdep.h' file in `sysdeps/unix' partially defines
-them; a `sysdep.h' file in another directory must finish defining them
-for the particular machine and operating system variant. See
-`sysdeps/unix/sysdep.h' and the machine-specific `sysdep.h'
-implementations to see what these macros are and what they should do.
-
- The system-specific makefile for the `unix' directory (that is, the
-file `sysdeps/unix/Makefile') gives rules to generate several files
-from the Unix system you are building the library on (which is assumed
-to be the target system you are building the library *for*). All the
-generated files are put in the directory where the object files are
-kept; they should not affect the source tree itself. The files
-generated are `ioctls.h', `errnos.h', `sys/param.h', and `errlist.c'
-(for the `stdio' section of the library).
-
-Contributors to the GNU C Library
-=================================
+ To correctly translate and install the Texinfo documentation you
+ need this version of the `texinfo' package. Earlier versions do
+ not understand all the tags used in the document, and the
+ installation mechanism for the info files is not present or works
+ differently.
- The GNU C library was written originally by Roland McGrath. Some
-parts of the library were contributed or worked on by other people.
+ * GNU `awk' 3.1.2, or higher
- * The `getopt' function and related code were written by Richard
- Stallman, David J. MacKenzie, and Roland McGrath.
+ `awk' is used in several places to generate files. Some `gawk'
+ extensions are used, including the `asorti' function, which was
+ introduced in version 3.1.2 of `gawk'.
- * The merge sort function `qsort' was written by Michael J. Haertel.
+ * Perl 5
- * The quick sort function used as a fallback by `qsort' was written
- by Douglas C. Schmidt.
+ Perl is not required, but it is used if present to test the
+ installation. We may decide to use it elsewhere in the future.
- * The memory allocation functions `malloc', `realloc' and `free' and
- related code were written by Michael J. Haertel.
+ * GNU `sed' 3.02 or newer
- * Fast implementations of many of the string functions (`memcpy',
- `strlen', etc.) were written by Torbjorn Granlund.
+ `Sed' is used in several places to generate files. Most scripts
+ work with any version of `sed'. The known exception is the script
+ `po2test.sed' in the `intl' subdirectory which is used to generate
+ `msgs.h' for the test suite. This script works correctly only
+ with GNU `sed' 3.02. If you like to run the test suite, you
+ should definitely upgrade `sed'.
- * The `tar.h' header file was written by David J. MacKenzie.
- * The port to the MIPS DECStation running Ultrix 4
- (`mips-dec-ultrix4') was contributed by Brendan Kehoe and Ian
- Lance Taylor.
+If you change any of the `configure.in' files you will also need
- * The DES encryption function `crypt' and related functions were
- contributed by Michael Glad.
+ * GNU `autoconf' 2.53 or higher
- * The `ftw' function was contributed by Ian Lance Taylor.
+and if you change any of the message translation files you will need
- * The startup code to support SunOS shared libraries was contributed
- by Tom Quinn.
+ * GNU `gettext' 0.10.36 or later
- * The `mktime' function was contributed by Paul Eggert.
+You may also need these packages if you upgrade your source tree using
+patches, although we try to avoid this.
- * The port to the Sequent Symmetry running Dynix version 3
- (`i386-sequent-bsd') was contributed by Jason Merrill.
+Specific advice for GNU/Linux systems
+=====================================
- * The timezone support code is derived from the public-domain
- timezone package by Arthur David Olson and his many contributors.
+If you are installing the GNU C Library on GNU/Linux systems, you need
+to have the header files from a 2.6.19.1 or newer kernel around for
+reference. These headers must be installed using `make
+headers_install'; the headers present in the kernel source directory
+are not suitable for direct use by the GNU C Library. You do not need
+to use that kernel, just have its headers installed where the GNU C
+Library can access them, referred to here as INSTALL-DIRECTORY. The
+easiest way to do this is to unpack it in a directory such as
+`/usr/src/linux-VERSION'. In that directory, run `make headers_install
+INSTALL_HDR_PATH=INSTALL-DIRECTORY'. Finally, configure the GNU C
+Library with the option `--with-headers=INSTALL-DIRECTORY/include'.
+Use the most recent kernel you can get your hands on. (If you are
+cross-compiling the GNU C Library, you need to specify
+`ARCH=ARCHITECTURE' in the `make headers_install' command, where
+ARCHITECTURE is the architecture name used by the Linux kernel, such as
+`x86' or `powerpc'.)
- * The port to the DEC Alpha running OSF/1 (`alpha-dec-osf1') was
- contributed by Brendan Kehoe, using some code written by Roland
- McGrath.
+ After installing the GNU C Library, you may need to remove or rename
+directories such as `/usr/include/linux' and `/usr/include/asm', and
+replace them with copies of directories such as `linux' and `asm' from
+`INSTALL-DIRECTORY/include'. All directories present in
+`INSTALL-DIRECTORY/include' should be copied, except that the GNU C
+Library provides its own version of `/usr/include/scsi'; the files
+provided by the kernel should be copied without replacing those
+provided by the GNU C Library. The `linux', `asm' and `asm-generic'
+directories are required to compile programs using the GNU C Library;
+the other directories describe interfaces to the kernel but are not
+required if not compiling programs using those interfaces. You do not
+need to copy kernel headers if you did not specify an alternate kernel
+header source using `--with-headers'.
- * The port to SGI machines running Irix 4 (`mips-sgi-irix4') was
- contributed by Tom Quinn.
+ The Filesystem Hierarchy Standard for GNU/Linux systems expects some
+components of the GNU C Library installation to be in `/lib' and some
+in `/usr/lib'. This is handled automatically if you configure the GNU
+C Library with `--prefix=/usr'. If you set some other prefix or allow
+it to default to `/usr/local', then all the components are installed
+there.
- * The port of the Mach and Hurd code to the MIPS architecture
- (`mips-ANYTHING-gnu') was contributed by Kazumoto Kojima.
+Reporting Bugs
+==============
- * The floating-point printing function used by `printf' and friends
- and the floating-point reading function used by `scanf', `strtod'
- and friends were written by Ulrich Drepper. The multi-precision
- integer functions used in those functions are taken from GNU MP,
- which was contributed by Torbjorn Granlund.
+There are probably bugs in the GNU C Library. There are certainly
+errors and omissions in this manual. If you report them, they will get
+fixed. If you don't, no one will ever know about them and they will
+remain unfixed for all eternity, if not longer.
- * The internationalization support in the library, and the support
- programs `locale' and `localedef', were written by Ulrich Drepper.
- Ulrich Drepper adapted the support code for message catalogs
- (`libintl.h', etc.) from the GNU `gettext' package, which he also
- wrote. He also contributed the `catgets' support and the entire
- suite of multi-byte and wide-character support functions
- (`wctype.h', `wchar.h', etc.).
+ It is a good idea to verify that the problem has not already been
+reported. Bugs are documented in two places: The file `BUGS' describes
+a number of well known bugs and the central GNU C Library bug tracking
+system has a WWW interface at `http://sourceware.org/bugzilla/'. The
+WWW interface gives you access to open and closed reports. A closed
+report normally includes a patch or a hint on solving the problem.
+
+ To report a bug, first you must find it. With any luck, this will
+be the hard part. Once you've found a bug, make sure it's really a
+bug. A good way to do this is to see if the GNU C Library behaves the
+same way some other C library does. If so, probably you are wrong and
+the libraries are right (but not necessarily). If not, one of the
+libraries is probably wrong. It might not be the GNU C Library. Many
+historical Unix C libraries permit things that we don't, such as
+closing a file twice.
+
+ If you think you have found some way in which the GNU C Library does
+not conform to the ISO and POSIX standards (*note Standards and
+Portability::), that is definitely a bug. Report it!
- * The implementations of the `nsswitch.conf' mechanism and the files
- and DNS backends for it were designed and written by Ulrich
- Drepper and Roland McGrath, based on a backend interface defined
- by Peter Eriksson.
+ Once you're sure you've found a bug, try to narrow it down to the
+smallest test case that reproduces the problem. In the case of a C
+library, you really only need to narrow it down to one library function
+call, if possible. This should not be too difficult.
- * The port to Linux i386/ELF (`i386-ANYTHING-linux') was contributed
- by Ulrich Drepper, based in large part on work done in Hongjiu
- Lu's Linux version of the GNU C Library.
+ The final step when you have a simple test case is to report the bug.
+Do this at `http://www.gnu.org/software/libc/bugs.html'.
- * The port to Linux/m68k (`m68k-ANYTHING-linux') was contributed by
- Andreas Schwab.
-
- * The ports to Linux/ARM (`arm-ANYTHING-linuxaout') and ARM standalone
- (`arm-ANYTHING-none'), as well as parts of the IPv6 support code, were
- contributed by Philip Blundell.
-
- * Richard Henderson contributed the ELF dynamic linking code and
- other support for the Alpha processor.
-
- * David Mosberger-Tang contributed the port to Linux/Alpha
- (`alpha-ANYTHING-linux').
-
- * Stephen R. van den Berg contributed a highly-optimized `strstr'
- function.
-
- * Ulrich Drepper contributed the `hsearch' and `drand48' families of
- functions; reentrant `...`_r'' versions of the `random' family;
- System V shared memory and IPC support code; and several
- highly-optimized string functions for iX86 processors.
-
- * The math functions are taken from `fdlibm-5.1' by Sun
- Microsystems, as modified by J.T. Conklin, Ian Lance Taylor,
- Ulrich Drepper, Andreas Schwab, and Roland McGrath.
-
- * The `libio' library used to implement `stdio' functions on some
- platforms was written by Per Bothner and modified by Ulrich
- Drepper.
-
- * Some of the Internet-related code (most of the `inet'
- subdirectory) and several other miscellaneous functions and
- header files have been included from 4.4 BSD with little or no
- modification.
-
- All code incorporated from 4.4 BSD is under the following
- copyright:
-
- Copyright (C) 1991 Regents of the University of California.
- All rights reserved.
-
- Redistribution and use in source and binary forms, with or
- without modification, are permitted provided that the
- following conditions are met:
-
- 1. Redistributions of source code must retain the above
- copyright notice, this list of conditions and the
- following disclaimer.
-
- 2. Redistributions in binary form must reproduce the above
- copyright notice, this list of conditions and the
- following disclaimer in the documentation and/or other
- materials provided with the distribution.
-
- 3. All advertising materials mentioning features or use of
- this software must display the following acknowledgement:
- This product includes software developed by the
- University of California, Berkeley and its
- contributors.
-
- 4. Neither the name of the University nor the names of its
- contributors may be used to endorse or promote products
- derived from this software without specific prior
- written permission.
-
- THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS
- IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
- FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
- SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
- INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
- OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
- LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
- THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
- OF SUCH DAMAGE.
-
- * The random number generation functions `random', `srandom',
- `setstate' and `initstate', which are also the basis for the
- `rand' and `srand' functions, were written by Earl T. Cohen for
- the University of California at Berkeley and are copyrighted by the
- Regents of the University of California. They have undergone minor
- changes to fit into the GNU C library and to fit the ANSI C
- standard, but the functional code is Berkeley's.
-
- * The Internet resolver code is taken directly from BIND 4.9.5,
- which is under both the Berkeley copyright above and also:
-
- Portions Copyright (C) 1993 by Digital Equipment Corporation.
-
- Permission to use, copy, modify, and distribute this software
- for any purpose with or without fee is hereby granted,
- provided that the above copyright notice and this permission
- notice appear in all copies, and that the name of Digital
- Equipment Corporation not be used in advertising or publicity
- pertaining to distribution of the document or software
- without specific, written prior permission.
-
- THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP.
- DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
- INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
- FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT CORPORATION BE
- LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
- DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
- DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
- WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
-
- * The code to support Sun RPC is taken verbatim from Sun's
- RPCSRC-4.0 distribution, and is covered by this copyright:
-
- Copyright (C) 1984, Sun Microsystems, Inc.
-
- Sun RPC is a product of Sun Microsystems, Inc. and is
- provided for unrestricted use provided that this legend is
- included on all tape media and as a part of the software
- program in whole or part. Users may copy or modify Sun RPC
- without charge, but are not authorized to license or
- distribute it to anyone else except as part of a product or
- program developed by the user.
-
- SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND
- INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND
- FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF
- DEALING, USAGE OR TRADE PRACTICE.
-
- Sun RPC is provided with no support and without any
- obligation on the part of Sun Microsystems, Inc. to assist in
- its use, correction, modification or enhancement.
-
- SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT
- TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY
- PATENTS BY SUN RPC OR ANY PART THEREOF.
-
- In no event will Sun Microsystems, Inc. be liable for any
- lost revenue or profits or other special, indirect and
- consequential damages, even if Sun has been advised of the
- possibility of such damages.
-
- Sun Microsystems, Inc.
- 2550 Garcia Avenue
- Mountain View, California 94043
-
- * Some of the support code for Mach is taken from Mach 3.0 by CMU,
- and is under the following copyright terms:
-
- Mach Operating System
- Copyright (C) 1991,1990,1989 Carnegie Mellon University
- All Rights Reserved.
-
- Permission to use, copy, modify and distribute this software
- and its documentation is hereby granted, provided that both
- the copyright notice and this permission notice appear in all
- copies of the software, derivative works or modified
- versions, and any portions thereof, and that both notices
- appear in supporting documentation.
-
- CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS
- IS" CONDITION. CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF
- ANY KIND FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF
- THIS SOFTWARE.
-
- Carnegie Mellon requests users of this software to return to
-
- Software Distribution Coordinator
- School of Computer Science
- Carnegie Mellon University
- Pittsburgh PA 15213-3890
-
- or `Software.Distribution@CS.CMU.EDU' any improvements or
- extensions that they make and grant Carnegie Mellon the
- rights to redistribute these changes.
-
- * The `getaddrinfo' function is written by Craig Metz and it has the
- following copyright:
-
- The Inner Net License, Version 2.00
- ===================================
-
- The author(s) grant permission for redistribution and use in source and
- binary forms, with or without modification, of the software
- and documentation provided that the following conditions are met:
-
- 0. If you receive a version of the software that is
- specifically labelled as not being for redistribution
- (check the version message and/or README), you are not
- permitted to redistribute that version of the software in
- any way or form.
- 1. All terms of the all other applicable copyrights and
- licenses must be followed.
- 2. Redistributions of source code must retain the authors'
- copyright notice(s), this list of conditions, and the
- following disclaimer.
- 3. Redistributions in binary form must reproduce the authors'
- copyright notice(s), this list of conditions, and the
- following disclaimer in the documentation and/or other
- materials provided with the distribution.
- 4. All advertising materials mentioning features or use of
- this software must display the following acknowledgement
- with the name(s) of the authors as specified in the
- copyright notice(s) substituted where indicated:
-
- This product includes software developed by <name(s)>, The Inner
- Net, and other contributors.
-
- 5. Neither the name(s) of the author(s) nor the names of its
- contributors may be used to endorse or promote products
- derived from this software without specific prior written
- permission.
-
- THIS SOFTWARE IS PROVIDED BY ITS AUTHORS AND CONTRIBUTORS ``AS
- IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
- FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
- SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
- INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
- OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
- LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
- THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
- OF SUCH DAMAGE.
-
- If these license terms cause you a real problem, contact the author.
-+
- * The `db' library is taken from the db-2.3.4 distribution by Sleepycat
- Software, and is covered by the following terms:
-
- /*-
- * @(#)LICENSE 10.4 (Sleepycat) 7/24/97
- */
-
- The following are the copyrights and redistribution conditions
- that apply to this copy of the DB software. For a license to use,
- redistribute or sell DB software under conditions other than those
- described here, or to purchase support for this software, please
- contact Sleepycat Software at one of the following addresses:
-
- Sleepycat Software db@sleepycat.com
- 394 E. Riding Dr. +1-508-287-4781
- Carlisle, MA 01741
- USA
-
- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- /*
- * Copyright (c) 1990, 1993, 1994, 1995, 1996, 1997
- * Sleepycat Software. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- * 3. Redistributions in any form must be accompanied by information on
- * how to obtain complete source code for the DB software and any
- * accompanying software that uses the DB software. The source code
- * must either be included in the distribution or be available for
- * no more than the cost of distribution plus a nominal fee, and
- * must be freely redistributable under reasonable conditions. For
- * an executable file, complete source code means the source code
- * for all modules it contains. It does not mean source code for
- * modules or files that typically accompany the operating system
- * on which the executable file runs, e.g., standard library
- * modules or system header files.
- *
- * THIS SOFTWARE IS PROVIDED BY SLEEPYCAT SOFTWARE ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
- * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
- * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL SLEEPYCAT
- * SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
- * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
- * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
- * THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
- /*
- * Copyright (c) 1990, 1993, 1994, 1995
- * The Regents of the University of California. All rights
- * reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- * 3. All advertising materials mentioning features or use of this
- * software must display the following acknowledgement:
- * This product includes software developed by the University of
- * California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its
- * contributors may be used to endorse or promote products derived
- * from this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS''
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
- * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
- * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS
- * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
- * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
- * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
- * THE POSSIBILITY OF SUCH DAMAGE.
- */
- /*
- * Copyright (c) 1995, 1996
- * The President and Fellows of Harvard University. All rights
- * reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- * 3. All advertising materials mentioning features or use of this
- * software must display the following acknowledgement:
- * This product includes software developed by Harvard University
- * and its contributors.
- * 4. Neither the name of the University nor the names of its
- * contributors may be used to endorse or promote products derived
- * from this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY HARVARD AND ITS CONTRIBUTORS ``AS IS''
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
- * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
- * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL HARVARD OR
- * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
- * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
- * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
- * POSSIBILITY OF SUCH DAMAGE.
- */
+ If you are not sure how a function should behave, and this manual
+doesn't tell you, that's a bug in the manual. Report that too! If the
+function's behavior disagrees with the manual, then either the library
+or the manual has a bug, so report the disagreement. If you find any
+errors or omissions in this manual, please report them to the bug
+database. If you refer to specific sections of the manual, please
+include the section names for easier identification.
projects / thirdparty / glibc.git / blobdiff