a5113b141c
Thu Aug 8 16:17:38 1996 Ulrich Drepper <drepper@cygnus.com> * pwd/getpwent.c: Define BUFLEN from NSS_BUFLEN_PASSWD. * pwd/getpwent_r.c: Likewise. * pwd/getpwnam.c: Likewise. * pwd/getpwnam_r.c: Likewise. * pwd/getpwuid.c: Likewise. * pwd/getpwuid_r.c: Likewise. * grp/getgrent.c: Define BUFLEN from NSS_BUFLEN_GROUP. * grp/getgrent_r.c: Likewise. * grp/getgrgid.c: Likewise. * grp/getgrgid_r.c: Likewise. * grp/getgrnam.c: Likewise. * pwd/fgetpwent_r.c: New file. Reentrant version of fgetpwent. * pwd/fgetpwent.c: Rewrite to use fgetpwent_r. * pwd/Makefile (routines): Add fgetpwent_r. * pwd/pwd.h: Add prototypes for __fgetpwent_r and fgetpwent_r. * grp/fgetgrent_r.c: New file. Reentrant version of fgetgrent. * grp/fgetgrent.c: Rewrite to use fgetgrent_r. * grp/Makefile (routines): Add fgetgrent_r. * grp/grp.h: Add prototypes for __fgetgrent_r and fgetgrent_r. Implement shadow password lookup functions. This is no complete shadow password suite. * shadow/Makefile: New file. * shadow/fgetspent.c: New file. * shadow/fgetspent_r.c: New file. * shadow/getspent.c: New file. * shadow/getspent_r.c: New file. * shadow/getspnam.c: New file. * shadow/getspnam_r.c: New file. * shadow/putspent.c: New file. * shadow/sgetspent.c: New file. * shadow/sgetspent_r.c: New file. * shadow/shadow.h: New file. * shadow/spwd-lookup.c: New file. * shadow/nss_files/files-spwd.c: New file. Thu Aug 8 13:33:45 1996 Ulrich Drepper <drepper@cygnus.com> * sysdeps/unix/sysv/linux/ftime.c: New file. Available system call is only a stub. Reported by Matthias Urlichs. * Makeconfig [!default_cflags]: Change default value from `-g' to `-g -O'. * configure.in: Recognize i686. * sysdeps/i386/i686/Implies: Default on i586 optimized code. Thu Aug 8 12:40:20 1996 Matthias Urlichs <smurf@smurf.noris.de> * Makeconfig [$(build-omitfp) == yes]: Add to CFLAGS-.so value of CFLAGS-.o, not CFLAGS-o. * sysdeps/unix/sysv/linux/init-first.c (init): Add volatile pointer to ourself. Otherwise `gcc -O3' optimized init away. sure that all tables in binary file are word-aligned.
914 lines
40 KiB
Plaintext
914 lines
40 KiB
Plaintext
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.
|
|
|
|
`--prefix=DIRECTORY'
|
|
Install machine-independent data files in subdirectories of
|
|
`DIRECTORY'. (You can also set this in `configparms'; see below.)
|
|
|
|
`--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
|
|
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
|
|
|
|
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.6
|
|
|
|
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.6 or later;
|
|
earlier versions are known to have problems.
|
|
|
|
Supported Configurations
|
|
------------------------
|
|
|
|
The GNU C Library currently supports configurations that match the
|
|
following patterns:
|
|
|
|
alpha-dec-osf1
|
|
alpha-ANYTHING-linux
|
|
alpha-ANYTHING-linuxecoff
|
|
iX86-ANYTHING-bsd4.3
|
|
iX86-ANYTHING-gnu
|
|
iX86-ANYTHING-isc2.2
|
|
iX86-ANYTHING-isc3.N
|
|
iX86-ANYTHING-linux
|
|
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
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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 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'.
|
|
|
|
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!
|
|
|
|
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.
|
|
|
|
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
|
|
=================================
|
|
|
|
The GNU C library was written originally by Roland McGrath. Some
|
|
parts of the library were contributed or worked on by other people.
|
|
|
|
* The `getopt' function and related code were written by Richard
|
|
Stallman, David J. MacKenzie, and Roland McGrath.
|
|
|
|
* The merge sort function `qsort' was written by Michael J. Haertel.
|
|
|
|
* The quick sort function used as a fallback by `qsort' was written
|
|
by Douglas C. Schmidt.
|
|
|
|
* The memory allocation functions `malloc', `realloc' and `free' and
|
|
related code were written by Michael J. Haertel.
|
|
|
|
* Fast implementations of many of the string functions (`memcpy',
|
|
`strlen', etc.) were written by Torbjorn Granlund.
|
|
|
|
* 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.
|
|
|
|
* The DES encryption function `crypt' and related functions were
|
|
contributed by Michael Glad.
|
|
|
|
* The `ftw' function was contributed by Ian Lance Taylor.
|
|
|
|
* The startup code to support SunOS shared libraries was contributed
|
|
by Tom Quinn.
|
|
|
|
* The `mktime' function was contributed by Paul Eggert.
|
|
|
|
* The port to the Sequent Symmetry running Dynix version 3
|
|
(`i386-sequent-bsd') was contributed by Jason Merrill.
|
|
|
|
* The timezone support code is derived from the public-domain
|
|
timezone package by Arthur David Olson and his many contributors.
|
|
|
|
* The port to the DEC Alpha running OSF/1 (`alpha-dec-osf1') was
|
|
contributed by Brendan Kehoe, using some code written by Roland
|
|
McGrath.
|
|
|
|
* The port to SGI machines running Irix 4 (`mips-sgi-irix4') was
|
|
contributed by Tom Quinn.
|
|
|
|
* The port of the Mach and Hurd code to the MIPS architecture
|
|
(`mips-ANYTHING-gnu') was contributed by Kazumoto Kojima.
|
|
|
|
* 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.
|
|
|
|
* 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.).
|
|
|
|
* 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.
|
|
|
|
* 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').
|
|
|
|
* 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.4,
|
|
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.
|
|
|