X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=INSTALL;h=5e538a6d586814bc4d2eeb04068e184c3c481c49;hb=95de6a9dcbc6bce6469d6dad95417a63b3920206;hp=242aaa676758bc322a751a02e237ee01bce5bb0d;hpb=845dcb57b1de1b8c2ea88cd101d6e5a80181ee4e;p=platform%2Fupstream%2Fglibc.git diff --git a/INSTALL b/INSTALL index 242aaa6..5e538a6 100644 --- a/INSTALL +++ b/INSTALL @@ -1,918 +1,486 @@ -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. - -`--without-fp' -`--nfp' - Use this option if your computer lacks hardware floating-point - support. +Installing the GNU C Library +**************************** + +Before you do anything else, you should read the FAQ at +. 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 -`--prefix=DIRECTORY' + $ ../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' +'--exec-prefix=DIRECTORY' Install the library and other machine-dependent files in - subdirectories of `DIRECTORY'. (You can also set this in - `configparms'; see below.) - -`--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. - -`--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'. - - 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 + 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. + +'--disable-shared' + 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. + +'--disable-profile' + Don't build libraries with profiling information. You may want to + use this option if you don't plan to do profiling. + +'--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 by default. + +'--enable-pt_chown' + The file 'pt_chown' is a helper binary for 'grantpt' (*note + Pseudo-Terminals: Allocation.) that is installed setuid root to fix + up pseudo-terminal ownership. It is not built by default because + systems using the Linux kernel are commonly built with the 'devpts' + filesystem enabled and mounted at '/dev/pts', which manages + pseudo-terminal ownership automatically. By using + '--enable-pt_chown', you may build 'pt_chown' and install it setuid + and owned by 'root'. The use of 'pt_chown' introduces additional + security risks to the system and you should enable it only if you + understand and accept those risks. + +'--disable-werror' + By default, the GNU C Library is built with '-Werror'. If you wish + to build without this option (for example, if building with a newer + version of GCC than this version of the GNU C Library was tested + with, so new warnings cause the build with '-Werror' to fail), you + can configure with '--disable-werror'. + +'--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 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. + + Normally, 'make check' will run all the tests before reporting all +problems found and exiting with error status if any problems occurred. +You can specify 'stop-on-test-failure=y' when running 'make check' to +make the test run stop and exit with an error status immediately when a +failure occurs. + + To format the 'GNU C Library Reference Manual' for printing, type +'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 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.) - - 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'. - - 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 ----------------------------------------------- - - We recommend installing the following GNU tools before attempting to -build the GNU C library: - - * `make' 3.75 - - 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 - - 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 +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 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. If multiple assignments to +the same variable are specified, the last assignment specified must take +precedence. + +Installing the C Library +======================== + +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; 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' if the '--enable-pt_chown' configuration option is used. This +program is invoked by the 'grantpt' function; it sets the permissions on +a pseudoterminal so it can be used by the calling process. If you are +using a Linux kernel with the 'devpts' filesystem enabled and mounted at +'/dev/pts', you don't need this program. + + 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 +================================= -Reporting Bugs -============== +We recommend installing the following GNU tools before attempting to +build the GNU C Library: - 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. + * GNU 'make' 3.79 or newer - 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 need the latest version of GNU 'make'. Modifying the GNU C + 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. - 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. + * GCC 4.6 or newer - 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'. + GCC 4.6 or higher is required. In general it is recommended to use + the newest version of the compiler that is known to work for + building the GNU C Library, as newer compilers usually produce + better code. As of release time, GCC 4.9.2 is the newest compiler + verified to work to build the GNU C Library. - 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 can use whatever compiler you like to compile programs that use + the GNU C Library. - 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. + Check the FAQ for any special compiler issues on particular + platforms. - 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 -implemented in assembly code in files in `sysdeps/unix'. These files -are named with a suffix of `.S'; for example, `__open.S'. Files ending -in `.S' are run through the C preprocessor before being fed to the -assembler. - - 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 -================================= + * GNU 'binutils' 2.22 or later + + 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. As of release time, GNU 'binutils' 2.25 is the newest + verified to work to build the GNU C Library. + + * GNU 'texinfo' 4.7 or later + + 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. As of release time, 'texinfo' 5.2 is the newest + verified to work to build the GNU C Library. - 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. +If you change any of the 'configure.ac' files you will also need - * The port to the MIPS DECStation running Ultrix 4 - (`mips-dec-ultrix4') was contributed by Brendan Kehoe and Ian - Lance Taylor. + * GNU 'autoconf' 2.69 (exactly) - * The DES encryption function `crypt' and related functions were - contributed by Michael Glad. +and if you change any of the message translation files you will need - * The `ftw' function was contributed by Ian Lance Taylor. + * GNU 'gettext' 0.10.36 or later - * The startup code to support SunOS shared libraries was contributed - by Tom Quinn. +If you wish to regenerate the 'yacc' parser code in the 'intl' +subdirectory you will need - * The `mktime' function was contributed by Paul Eggert. + * GNU 'bison' 2.7 or later - * The port to the Sequent Symmetry running Dynix version 3 - (`i386-sequent-bsd') was contributed by Jason Merrill. +You may also need these packages if you upgrade your source tree using +patches, although we try to avoid this. - * The timezone support code is derived from the public-domain - timezone package by Arthur David Olson and his many contributors. +Specific advice for GNU/Linux systems +===================================== - * The port to the DEC Alpha running OSF/1 (`alpha-dec-osf1') was - contributed by Brendan Kehoe, using some code written by Roland - McGrath. +If you are installing the GNU C Library on GNU/Linux systems, you need +to have the header files from a 2.6.32 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 SGI machines running Irix 4 (`mips-sgi-irix4') was - contributed by Tom Quinn. + 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 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. + +Reporting Bugs +============== + +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 port of the Mach and Hurd code to the MIPS architecture - (`mips-ANYTHING-gnu') was contributed by Kazumoto Kojima. + 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 . 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. - * 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. + 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. - * 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.). + 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 port to Linux/m68k (`m68k-ANYTHING-linux') was contributed by - Andreas Schwab. - - * 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'). + The final step when you have a simple test case is to report the bug. +Do this at . - * 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. - - * 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. + 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.