Fri Jul 5 12:22:51 1996 Roland McGrath <roland@delasyd.gnu.ai.mit.edu>
[glibc.git] / INSTALL
blob1476bd82468ab5aa5611669a379c951ad51a2171
1 Library Maintenance
2 *******************
4 How to Install the GNU C Library
5 ================================
7    Installation of the GNU C library is relatively simple.
9    You need the latest version of GNU `make'.  Modifying the GNU C
10 Library to work with other `make' programs would be so hard that we
11 recommend you port GNU `make' instead.  *Really.*
13    To configure the GNU C library for your system, run the shell script
14 `configure' with `sh'.  Use an argument which is the conventional GNU
15 name for your system configuration--for example, `sparc-sun-sunos4.1',
16 for a Sun 4 running Sunos 4.1.  *Note Installation:
17 (gcc.info)Installation, for a full description of standard GNU
18 configuration names.  If you omit the configuration name, `configure'
19 will try to guess one for you by inspecting the system it is running
20 on.  It may or may not be able to come up with a guess, and the its
21 guess might be wrong.  `configure' will tell you the canonical name of
22 the chosen configuration before proceeding.
24    The GNU C Library currently supports configurations that match the
25 following patterns:
27      alpha-dec-osf1
28      i386-ANYTHING-bsd4.3
29      i386-ANYTHING-gnu
30      i386-ANYTHING-isc2.2
31      i386-ANYTHING-isc3.N
32      i386-ANYTHING-sco3.2
33      i386-ANYTHING-sco3.2v4
34      i386-ANYTHING-sysv
35      i386-ANYTHING-sysv4
36      i386-force_cpu386-none
37      i386-sequent-bsd
38      i960-nindy960-none
39      m68k-hp-bsd4.3
40      m68k-mvme135-none
41      m68k-mvme136-none
42      m68k-sony-newsos3
43      m68k-sony-newsos4
44      m68k-sun-sunos4.N
45      mips-dec-ultrix4.N
46      mips-sgi-irix4.N
47      sparc-sun-solaris2.N
48      sparc-sun-sunos4.N
50    While no other configurations are supported, there are handy aliases
51 for these few.  (These aliases work in other GNU software as well.)
53      decstation
54      hp320-bsd4.3 hp300bsd
55      i386-sco
56      i386-sco3.2v4
57      i386-sequent-dynix
58      i386-svr4
59      news
60      sun3-sunos4.N sun3
61      sun4-solaris2.N sun4-sunos5.N
62      sun4-sunos4.N sun4
64    Here are some options that you should specify (if appropriate) when
65 you run `configure':
67 `--with-gnu-ld'
68      Use this option if you plan to use GNU `ld' to link programs with
69      the GNU C Library.  (We strongly recommend that you do.)  This
70      option enables use of features that exist only in GNU `ld'; so if
71      you configure for GNU `ld' you must use GNU `ld' *every time* you
72      link with the GNU C Library, and when building it.
74 `--with-gnu-as'
75      Use this option if you plan to use the GNU assembler, `gas', when
76      building the GNU C Library.  On some systems, the library may not
77      build properly if you do *not* use `gas'.
79 `--nfp'
80      Use this option if your computer lacks hardware floating point
81      support.
83 `--prefix=DIRECTORY'
84      Install machine-independent data files in subdirectories of
85      `DIRECTORY'.  (You can also set this in `configparms'; see below.)
87 `--exec-prefix=DIRECTORY'
88      Install the library and other machine-dependent files in
89      subdirectories of `DIRECTORY'.  (You can also set this in
90      `configparms'; see below.)
92    The simplest way to run `configure' is to do it in the directory
93 that contains the library sources.  This prepares to build the library
94 in that very directory.
96    You can prepare to build the library in some other directory by going
97 to that other directory to run `configure'.  In order to run configure,
98 you will have to specify a directory for it, like this:
100      mkdir sun4
101      cd sun4
102      ../configure sparc-sun-sunos4.1
104 `configure' looks for the sources in whatever directory you specified
105 for finding `configure' itself.  It does not matter where in the file
106 system the source and build directories are--as long as you specify the
107 source directory when you run `configure', you will get the proper
108 results.
110    This feature lets you keep sources and binaries in different
111 directories, and that makes it easy to build the library for several
112 different machines from the same set of sources.  Simply create a build
113 directory for each target machine, and run `configure' in that
114 directory specifying the target machine's configuration name.
116    The library has a number of special-purpose configuration parameters.
117 These are defined in the file `Makeconfig'; see the comments in that
118 file for the details.
120    But don't edit the file `Makeconfig' yourself--instead, create a
121 file `configparms' in the directory where you are building the library,
122 and define in that file the parameters you want to specify.
123 `configparms' should *not* be an edited copy of `Makeconfig'; specify
124 only the parameters that you want to override.  To see how to set these
125 parameters, find the section of `Makeconfig' that says "These are the
126 configuration variables." Then for each parameter that you want to
127 change, copy the definition from `Makeconfig' to your new `configparms'
128 file, and change the value as appropriate for your system.
130    It is easy to configure the GNU C library for cross-compilation by
131 setting a few variables in `configparms'.  Set `CC' to the
132 cross-compiler for the target you configured the library for; it is
133 important to use this same `CC' value when running `configure', like
134 this: `CC=TARGET-gcc configure TARGET'.  Set `BUILD_CC' to the compiler
135 to use for for programs run on the build system as part of compiling
136 the library.  You may need to set `AR' and `RANLIB' to cross-compiling
137 versions of `ar' and `ranlib' if the native tools are not configured to
138 work with object files for the target you configured for.
140    Some of the machine-dependent code for some machines uses extensions
141 in the GNU C compiler, so you may need to compile the library with GCC.
142 (In fact, all of the existing complete ports require GCC.)
144    The current release of the C library contains some header files that
145 the compiler normally provides: `stddef.h', `stdarg.h', and several
146 files with names of the form `va-MACHINE.h'.  The versions of these
147 files that came with older releases of GCC do not work properly with
148 the GNU C library.  The `stddef.h' file in release 2.2 and later of GCC
149 is correct.  If you have release 2.2 or later of GCC, use its version
150 of `stddef.h' instead of the C library's.  To do this, put the line
151 `override stddef.h =' in `configparms'.  The other files are corrected
152 in release 2.3 and later of GCC.  `configure' will automatically detect
153 whether the installed `stdarg.h' and `va-MACHINE.h' files are
154 compatible with the C library, and use its own if not.
156    There is a potential problem with the `size_t' type and versions of
157 GCC prior to release 2.4.  ANSI C requires that `size_t' always be an
158 unsigned type.  For compatibility with existing systems' header files,
159 GCC defines `size_t' in `stddef.h' to be whatever type the system's
160 `sys/types.h' defines it to be.  Most Unix systems that define `size_t'
161 in `sys/types.h', define it to be a signed type.  Some code in the
162 library depends on `size_t' being an unsigned type, and will not work
163 correctly if it is signed.
165    The GNU C library code which expects `size_t' to be unsigned is
166 correct.  The definition of `size_t' as a signed type is incorrect.
167 Versions 2.4 and later of GCC always define `size_t' as an unsigned
168 type, and GCC's `fixincludes' script massages the system's
169 `sys/types.h' so as not to conflict with this.
171    In the meantime, we work around this problem by telling GCC
172 explicitly to use an unsigned type for `size_t' when compiling the GNU C
173 library.  `configure' will automatically detect what type GCC uses for
174 `size_t' arrange to override it if necessary.
176    To build the library, type `make lib'.  This will produce a lot of
177 output, some of which looks like errors from `make' (but isn't).  Look
178 for error messages from `make' containing `***'.  Those indicate that
179 something is really wrong.
181    To build and run some test programs which exercise some of the
182 library facilities, type `make tests'.  This will produce several files
183 with names like `PROGRAM.out'.
185    To format the `GNU C Library Reference Manual' for printing, type
186 `make dvi'.  To format the Info version of the manual for on line
187 reading with `C-h i' in Emacs or with the `info' program, type
188 `make info'.
190    To install the library and its header files, and the Info files of
191 the manual, type `make install', after setting the installation
192 directories in `configparms'.  This will build things if necessary,
193 before installing them.
195 Reporting Bugs
196 ==============
198    There are probably bugs in the GNU C library.  There are certainly
199 errors and omissions in this manual.  If you report them, they will get
200 fixed.  If you don't, no one will ever know about them and they will
201 remain unfixed for all eternity, if not longer.
203    To report a bug, first you must find it.  Hopefully, this will be the
204 hard part.  Once you've found a bug, make sure it's really a bug.  A
205 good way to do this is to see if the GNU C library behaves the same way
206 some other C library does.  If so, probably you are wrong and the
207 libraries are right (but not necessarily).  If not, one of the libraries
208 is probably wrong.
210    Once you're sure you've found a bug, try to narrow it down to the
211 smallest test case that reproduces the problem.  In the case of a C
212 library, you really only need to narrow it down to one library function
213 call, if possible.  This should not be too difficult.
215    The final step when you have a simple test case is to report the bug.
216 When reporting a bug, send your test case, the results you got, the
217 results you expected, what you think the problem might be (if you've
218 thought of anything), your system type, and the version of the GNU C
219 library which you are using.  Also include the files `config.status'
220 and `config.make' which are created by running `configure'; they will
221 be in whatever directory was current when you ran `configure'.
223    If you think you have found some way in which the GNU C library does
224 not conform to the ANSI and POSIX standards (*note Standards and
225 Portability::.), that is definitely a bug.  Report it!
227    Send bug reports to the Internet address `bug-glibc@prep.ai.mit.edu'
228 or the UUCP path `mit-eddie!prep.ai.mit.edu!bug-glibc'.  If you have
229 other problems with installation or use, please report those as well.
231    If you are not sure how a function should behave, and this manual
232 doesn't tell you, that's a bug in the manual.  Report that too!  If the
233 function's behavior disagrees with the manual, then either the library
234 or the manual has a bug, so report the disagreement.  If you find any
235 errors or omissions in this manual, please report them to the Internet
236 address `bug-glibc-manual@prep.ai.mit.edu' or the UUCP path
237 `mit-eddie!prep.ai.mit.edu!bug-glibc-manual'.
239 Adding New Functions
240 ====================
242    The process of building the library is driven by the makefiles, which
243 make heavy use of special features of GNU `make'.  The makefiles are
244 very complex, and you probably don't want to try to understand them.
245 But what they do is fairly straightforward, and only requires that you
246 define a few variables in the right places.
248    The library sources are divided into subdirectories, grouped by
249 topic.  The `string' subdirectory has all the string-manipulation
250 functions, `stdio' has all the standard I/O functions, etc.
252    Each subdirectory contains a simple makefile, called `Makefile',
253 which defines a few `make' variables and then includes the global
254 makefile `Rules' with a line like:
256      include ../Rules
258 The basic variables that a subdirectory makefile defines are:
260 `subdir'
261      The name of the subdirectory, for example `stdio'.  This variable
262      *must* be defined.
264 `headers'
265      The names of the header files in this section of the library, such
266      as `stdio.h'.
268 `routines'
269 `aux'
270      The names of the modules (source files) in this section of the
271      library.  These should be simple names, such as `strlen' (rather
272      than complete file names, such as `strlen.c').  Use `routines' for
273      modules that define functions in the library, and `aux' for
274      auxiliary modules containing things like data definitions.  But the
275      values of `routines' and `aux' are just concatenated, so there
276      really is no practical difference.
278 `tests'
279      The names of test programs for this section of the library.  These
280      should be simple names, such as `tester' (rather than complete file
281      names, such as `tester.c').  `make tests' will build and run all
282      the test programs.  If a test program needs input, put the test
283      data in a file called `TEST-PROGRAM.input'; it will be given to
284      the test program on its standard input.  If a test program wants
285      to be run with arguments, put the arguments (all on a single line)
286      in a file called `TEST-PROGRAM.args'.
288 `others'
289      The names of "other" programs associated with this section of the
290      library.  These are programs which are not tests per se, but are
291      other small programs included with the library.  They are built by
292      `make others'.
294 `install-lib'
295 `install-data'
296 `install'
297      Files to be installed by `make install'.  Files listed in
298      `install-lib' are installed in the directory specified by `libdir'
299      in `configparms' or `Makeconfig' (*note Installation::.).  Files
300      listed in `install-data' are installed in the directory specified
301      by `datadir' in `configparms' or `Makeconfig'.  Files listed in
302      `install' are installed in the directory specified by `bindir' in
303      `configparms' or `Makeconfig'.
305 `distribute'
306      Other files from this subdirectory which should be put into a
307      distribution tar file.  You need not list here the makefile itself
308      or the source and header files listed in the other standard
309      variables.  Only define `distribute' if there are files used in an
310      unusual way that should go into the distribution.
312 `generated'
313      Files which are generated by `Makefile' in this subdirectory.
314      These files will be removed by `make clean', and they will never
315      go into a distribution.
317 `extra-objs'
318      Extra object files which are built by `Makefile' in this
319      subdirectory.  This should be a list of file names like `foo.o';
320      the files will actually be found in whatever directory object
321      files are being built in.  These files will be removed by
322      `make clean'.  This variable is used for secondary object files
323      needed to build `others' or `tests'.
325 Porting the GNU C Library
326 =========================
328    The GNU C library is written to be easily portable to a variety of
329 machines and operating systems.  Machine- and operating system-dependent
330 functions are well separated to make it easy to add implementations for
331 new machines or operating systems.  This section describes the layout of
332 the library source tree and explains the mechanisms used to select
333 machine-dependent code to use.
335    All the machine-dependent and operating system-dependent files in the
336 library are in the subdirectory `sysdeps' under the top-level library
337 source directory.  This directory contains a hierarchy of
338 subdirectories (*note Hierarchy Conventions::.).
340    Each subdirectory of `sysdeps' contains source files for a
341 particular machine or operating system, or for a class of machine or
342 operating system (for example, systems by a particular vendor, or all
343 machines that use IEEE 754 floating-point format).  A configuration
344 specifies an ordered list of these subdirectories.  Each subdirectory
345 implicitly appends its parent directory to the list.  For example,
346 specifying the list `unix/bsd/vax' is equivalent to specifying the list
347 `unix/bsd/vax unix/bsd unix'.  A subdirectory can also specify that it
348 implies other subdirectories which are not directly above it in the
349 directory hierarchy.  If the file `Implies' exists in a subdirectory,
350 it lists other subdirectories of `sysdeps' which are appended to the
351 list, appearing after the subdirectory containing the `Implies' file.
352 Lines in an `Implies' file that begin with a `#' character are ignored
353 as comments.  For example, `unix/bsd/Implies' contains:
354      # BSD has Internet-related things.
355      unix/inet
357 and `unix/Implies' contains:
358      posix
360 So the final list is `unix/bsd/vax unix/bsd unix/inet unix posix'.
362    `sysdeps' has two "special" subdirectories, called `generic' and
363 `stub'.  These two are always implicitly appended to the list of
364 subdirectories (in that order), so you needn't put them in an `Implies'
365 file, and you should not create any subdirectories under them.
366 `generic' is for things that can be implemented in machine-independent
367 C, using only other machine-independent functions in the C library.
368 `stub' is for "stub" versions of functions which cannot be implemented
369 on a particular machine or operating system.  The stub functions always
370 return an error, and set `errno' to `ENOSYS' (Function not
371 implemented).  *Note Error Reporting::.
373    A source file is known to be system-dependent by its having a
374 version in `generic' or `stub'; every system-dependent function should
375 have either a generic or stub implementation (there is no point in
376 having both).
378    If you come across a file that is in one of the main source
379 directories (`string', `stdio', etc.), and you want to write a machine-
380 or operating system-dependent version of it, move the file into
381 `sysdeps/generic' and write your new implementation in the appropriate
382 system-specific subdirectory.  Note that if a file is to be
383 system-dependent, it *must not* appear in one of the main source
384 directories.
386    There are a few special files that may exist in each subdirectory of
387 `sysdeps':
389 `Makefile'
390      A makefile for this machine or operating system, or class of
391      machine or operating system.  This file is included by the library
392      makefile `Makerules', which is used by the top-level makefile and
393      the subdirectory makefiles.  It can change the variables set in the
394      including makefile or add new rules.  It can use GNU `make'
395      conditional directives based on the variable `subdir' (see above)
396      to select different sets of variables and rules for different
397      sections of the library.  It can also set the `make' variable
398      `sysdep-routines', to specify extra modules to be included in the
399      library.  You should use `sysdep-routines' rather than adding
400      modules to `routines' because the latter is used in determining
401      what to distribute for each subdirectory of the main source tree.
403      Each makefile in a subdirectory in the ordered list of
404      subdirectories to be searched is included in order.  Since several
405      system-dependent makefiles may be included, each should append to
406      `sysdep-routines' rather than simply setting it:
408           sysdep-routines := $(sysdep-routines) foo bar
410 `Subdirs'
411      This file contains the names of new whole subdirectories under the
412      top-level library source tree that should be included for this
413      system.  These subdirectories are treated just like the
414      system-independent subdirectories in the library source tree, such
415      as `stdio' and `math'.
417      Use this when there are completely new sets of functions and header
418      files that should go into the library for the system this
419      subdirectory of `sysdeps' implements.  For example,
420      `sysdeps/unix/inet/Subdirs' contains `inet'; the `inet' directory
421      contains various network-oriented operations which only make sense
422      to put in the library on systems that support the Internet.
424 `Dist'
425      This file contains the names of files (relative to the
426      subdirectory of `sysdeps' in which it appears) which should be
427      included in the distribution.  List any new files used by rules in
428      the `Makefile' in the same directory, or header files used by the
429      source files in that directory.  You don't need to list files that
430      are implementations (either C or assembly source) of routines
431      whose names are given in the machine-independent makefiles in the
432      main source tree.
434 `configure'
435      This file is a shell script fragment to be run at configuration
436      time.  The top-level `configure' script uses the shell `.' command
437      to read the `configure' file in each system-dependent directory
438      chosen, in order.  The `configure' files are often generated from
439      `configure.in' files using Autoconf.
441      A system-dependent `configure' script will usually add things to
442      the shell variables `DEFS' and `config_vars'; see the top-level
443      `configure' script for details.  The script can check for
444      `--with-PACKAGE' options that were passed to the top-level
445      `configure'.  For an option `--with-PACKAGE=VALUE' `configure'
446      sets the shell variable `with_PACKAGE' (with any dashes in PACKAGE
447      converted to underscores) to VALUE; if the option is just
448      `--with-PACKAGE' (no argument), then it sets `with_PACKAGE' to
449      `yes'.
451 `configure.in'
452      This file is an Autoconf input fragment to be processed into the
453      file `configure' in this subdirectory.  *Note Introduction:
454      (autoconf.info)Introduction, for a description of Autoconf.  You
455      should write either `configure' or `configure.in', but not both.
456      The first line of `configure.in' should invoke the `m4' macro
457      `GLIBC_PROVIDES'.  This macro does several `AC_PROVIDE' calls for
458      Autoconf macros which are used by the top-level `configure'
459      script; without this, those macros might be invoked again
460      unnecessarily by Autoconf.
462    That is the general system for how system-dependencies are isolated.
464 Layout of the `sysdeps' Directory Hierarchy
465 -------------------------------------------
467    A GNU configuration name has three parts: the CPU type, the
468 manufacturer's name, and the operating system.  `configure' uses these
469 to pick the list of system-dependent directories to look for.  If the
470 `--nfp' option is *not* passed to `configure', the directory
471 `MACHINE/fpu' is also used.  The operating system often has a "base
472 operating system"; for example, if the operating system is `sunos4.1',
473 the base operating system is `unix/bsd'.  The algorithm used to pick
474 the list of directories is simple: `configure' makes a list of the base
475 operating system, manufacturer, CPU type, and operating system, in that
476 order.  It then concatenates all these together with slashes in
477 between, to produce a directory name; for example, the configuration
478 `sparc-sun-sunos4.1' results in `unix/bsd/sun/sparc/sunos4.1'.
479 `configure' then tries removing each element of the list in turn, so
480 `unix/bsd/sparc' and `sun/sparc' are also tried, among others.  Since
481 the precise version number of the operating system is often not
482 important, and it would be very inconvenient, for example, to have
483 identical `sunos4.1.1' and `sunos4.1.2' directories, `configure' tries
484 successively less specific operating system names by removing trailing
485 suffixes starting with a period.
487    As an example, here is the complete list of directories that would be
488 tried for the configuration `sparc-sun-sunos4.1' (without the `--nfp'
489 option):
491      sparc/fpu
492      unix/bsd/sun/sunos4.1/sparc
493      unix/bsd/sun/sunos4.1
494      unix/bsd/sun/sunos4/sparc
495      unix/bsd/sun/sunos4
496      unix/bsd/sun/sunos/sparc
497      unix/bsd/sun/sunos
498      unix/bsd/sun/sparc
499      unix/bsd/sun
500      unix/bsd/sunos4.1/sparc
501      unix/bsd/sunos4.1
502      unix/bsd/sunos4/sparc
503      unix/bsd/sunos4
504      unix/bsd/sunos/sparc
505      unix/bsd/sunos
506      unix/bsd/sparc
507      unix/bsd
508      unix/sun/sunos4.1/sparc
509      unix/sun/sunos4.1
510      unix/sun/sunos4/sparc
511      unix/sun/sunos4
512      unix/sun/sunos/sparc
513      unix/sun/sunos
514      unix/sun/sparc
515      unix/sun
516      unix/sunos4.1/sparc
517      unix/sunos4.1
518      unix/sunos4/sparc
519      unix/sunos4
520      unix/sunos/sparc
521      unix/sunos
522      unix/sparc
523      unix
524      sun/sunos4.1/sparc
525      sun/sunos4.1
526      sun/sunos4/sparc
527      sun/sunos4
528      sun/sunos/sparc
529      sun/sunos
530      sun/sparc
531      sun
532      sunos4.1/sparc
533      sunos4.1
534      sunos4/sparc
535      sunos4
536      sunos/sparc
537      sunos
538      sparc
540    Different machine architectures are conventionally subdirectories at
541 the top level of the `sysdeps' directory tree.  For example,
542 `sysdeps/sparc' and `sysdeps/m68k'.  These contain files specific to
543 those machine architectures, but not specific to any particular
544 operating system.  There might be subdirectories for specializations of
545 those architectures, such as `sysdeps/m68k/68020'. Code which is
546 specific to the floating-point coprocessor used with a particular
547 machine should go in `sysdeps/MACHINE/fpu'.
549    There are a few directories at the top level of the `sysdeps'
550 hierarchy that are not for particular machine architectures.
552 `generic'
553 `stub'
554      As described above (*note Porting::.), these are the two
555      subdirectories that every configuration implicitly uses after all
556      others.
558 `ieee754'
559      This directory is for code using the IEEE 754 floating-point
560      format, where the C type `float' is IEEE 754 single-precision
561      format, and `double' is IEEE 754 double-precision format.  Usually
562      this directory is referred to in the `Implies' file in a machine
563      architecture-specific directory, such as `m68k/Implies'.
565 `posix'
566      This directory contains implementations of things in the library in
567      terms of POSIX.1 functions.  This includes some of the POSIX.1
568      functions themselves.  Of course, POSIX.1 cannot be completely
569      implemented in terms of itself, so a configuration using just
570      `posix' cannot be complete.
572 `unix'
573      This is the directory for Unix-like things.  *Note Porting to
574      Unix::.  `unix' implies `posix'.  There are some special-purpose
575      subdirectories of `unix':
577     `unix/common'
578           This directory is for things common to both BSD and System V
579           release 4.  Both `unix/bsd' and `unix/sysv/sysv4' imply
580           `unix/common'.
582     `unix/inet'
583           This directory is for `socket' and related functions on Unix
584           systems.  The `inet' top-level subdirectory is enabled by
585           `unix/inet/Subdirs'.  `unix/common' implies `unix/inet'.
587 `mach'
588      This is the directory for things based on the Mach microkernel
589      from CMU (including the GNU operating system).  Other basic
590      operating systems (VMS, for example) would have their own
591      directories at the top level of the `sysdeps' hierarchy, parallel
592      to `unix' and `mach'.
594 Porting the GNU C Library to Unix Systems
595 -----------------------------------------
597    Most Unix systems are fundamentally very similar.  There are
598 variations between different machines, and variations in what
599 facilities are provided by the kernel.  But the interface to the
600 operating system facilities is, for the most part, pretty uniform and
601 simple.
603    The code for Unix systems is in the directory `unix', at the top
604 level of the `sysdeps' hierarchy.  This directory contains
605 subdirectories (and subdirectory trees) for various Unix variants.
607    The functions which are system calls in most Unix systems are
608 implemented in assembly code in files in `sysdeps/unix'.  These files
609 are named with a suffix of `.S'; for example, `__open.S'.  Files ending
610 in `.S' are run through the C preprocessor before being fed to the
611 assembler.
613    These files all use a set of macros that should be defined in
614 `sysdep.h'.  The `sysdep.h' file in `sysdeps/unix' partially defines
615 them; a `sysdep.h' file in another directory must finish defining them
616 for the particular machine and operating system variant.  See
617 `sysdeps/unix/sysdep.h' and the machine-specific `sysdep.h'
618 implementations to see what these macros are and what they should do.
620    The system-specific makefile for the `unix' directory (that is, the
621 file `sysdeps/unix/Makefile') gives rules to generate several files
622 from the Unix system you are building the library on (which is assumed
623 to be the target system you are building the library *for*).  All the
624 generated files are put in the directory where the object files are
625 kept; they should not affect the source tree itself.  The files
626 generated are `ioctls.h', `errnos.h', `sys/param.h', and `errlist.c'
627 (for the `stdio' section of the library).
629 Contributors to the GNU C Library
630 =================================
632    The GNU C library was written almost entirely by Roland McGrath, who
633 now maintains it.  Some parts of the library were contributed or worked
634 on by other people.
636    * The `getopt' function and related code were written by Richard
637      Stallman, David J. MacKenzie, and Roland McGrath.
639    * Most of the math functions are taken from 4.4 BSD; they have been
640      modified only slightly to work with the GNU C library.  The
641      Internet-related code (most of the `inet' subdirectory) and several
642      other miscellaneous functions and header files have been included
643      with little or no modification.
645      All code incorporated from 4.4 BSD is under the following
646      copyright:
648                Copyright (C) 1991 Regents of the University of California.
649                All rights reserved.
651           Redistribution and use in source and binary forms, with or
652           without modification, are permitted provided that the
653           following conditions are met:
655             1. Redistributions of source code must retain the above
656                copyright notice, this list of conditions and the
657                following disclaimer.
659             2. Redistributions in binary form must reproduce the above
660                copyright notice, this list of conditions and the
661                following disclaimer in the documentation and/or other
662                materials provided with the distribution.
664             3. All advertising materials mentioning features or use of
665                this software must display the following acknowledgement:
666                     This product includes software developed by the
667                     University of California, Berkeley and its
668                     contributors.
670             4. Neither the name of the University nor the names of its
671                contributors may be used to endorse or promote products
672                derived from this software without specific prior
673                written permission.
675           THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS
676           IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
677           LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
678           FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT
679           SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
680           INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
681           DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
682           SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
683           OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
684           LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
685           (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
686           THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
687           OF SUCH DAMAGE.
689    * The random number generation functions `random', `srandom',
690      `setstate' and `initstate', which are also the basis for the
691      `rand' and `srand' functions, were written by Earl T. Cohen for
692      the University of California at Berkeley and are copyrighted by the
693      Regents of the University of California.  They have undergone minor
694      changes to fit into the GNU C library and to fit the ANSI C
695      standard, but the functional code is Berkeley's.
697    * The merge sort function `qsort' was written by Michael J. Haertel.
699    * The quick sort function used as a fallback by `qsort' was written
700      by Douglas C. Schmidt.
702    * The memory allocation functions `malloc', `realloc' and `free' and
703      related code were written by Michael J. Haertel.
705    * Fast implementations of many of the string functions (`memcpy',
706      `strlen', etc.) were written by Torbjorn Granlund.
708    * Some of the support code for Mach is taken from Mach 3.0 by CMU,
709      and is under the following copyright terms:
711                Mach Operating System
712                Copyright (C) 1991,1990,1989 Carnegie Mellon University
713                All Rights Reserved.
715           Permission to use, copy, modify and distribute this software
716           and its documentation is hereby granted, provided that both
717           the copyright notice and this permission notice appear in all
718           copies of the software, derivative works or modified
719           versions, and any portions thereof, and that both notices
720           appear in supporting documentation.
722           CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS
723           IS" CONDITION.  CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF
724           ANY KIND FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF
725           THIS SOFTWARE.
727           Carnegie Mellon requests users of this software to return to
729                 Software Distribution Coordinator
730                 School of Computer Science
731                 Carnegie Mellon University
732                 Pittsburgh PA 15213-3890
734           or `Software.Distribution@CS.CMU.EDU' any improvements or
735           extensions that they make and grant Carnegie Mellon the
736           rights to redistribute these changes.
738    * The `tar.h' header file was written by David J. MacKenzie.
740    * The port to the MIPS DECStation running Ultrix 4
741      (`mips-dec-ultrix4') was contributed by Brendan Kehoe and Ian
742      Lance Taylor.
744    * The DES encryption function `crypt' and related functions were
745      contributed by Michael Glad.
747    * The `ftw' function was contributed by Ian Lance Taylor.
749    * The code to support SunOS shared libraries was contributed by Tom
750      Quinn.
752    * The `mktime' function was contributed by Noel Cragg.
754    * The port to the Sequent Symmetry running Dynix version 3
755      (`i386-sequent-bsd') was contributed by Jason Merrill.
757    * The timezone support code is derived from the public-domain
758      timezone package by Arthur David Olson.
760    * The Internet resolver code is taken directly from BIND 4.9.1,
761      which is under both the Berkeley copyright above and also:
763           Portions Copyright (C) 1993 by Digital Equipment Corporation.
765           Permission to use, copy, modify, and distribute this software
766           for any purpose with or without fee is hereby granted,
767           provided that the above copyright notice and this permission
768           notice appear in all copies, and that the name of Digital
769           Equipment Corporation not be used in advertising or publicity
770           pertaining to distribution of the document or software
771           without specific, written prior permission.
773           THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP.
774           DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
775           INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
776           FITNESS.  IN NO EVENT SHALL DIGITAL EQUIPMENT CORPORATION BE
777           LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
778           DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
779           DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
780           OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
781           WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
783    * The port to the DEC Alpha running OSF/1 (`alpha-dec-osf1') was
784      contributed by Brendan Kehoe, using some code written by Roland
785      McGrath.
787    * The floating-point printing function used by `printf' and friends
788      was written by Roland McGrath and Torbjorn Granlund.  The
789      multi-precision integer functions used in that function are taken
790      from GNU MP, which was contributed by Torbjorn Granlund.
792    * The code to support Sun RPC is taken verbatim from Sun's
793      RPCSRC-4.0 distribution, and is covered by this copyright:
795                Copyright (C) 1984, Sun Microsystems, Inc.
797           Sun RPC is a product of Sun Microsystems, Inc. and is
798           provided for unrestricted use provided that this legend is
799           included on all tape media and as a part of the software
800           program in whole or part.  Users may copy or modify Sun RPC
801           without charge, but are not authorized to license or
802           distribute it to anyone else except as part of a product or
803           program developed by the user.
805           SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND
806           INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND
807           FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF
808           DEALING, USAGE OR TRADE PRACTICE.
810           Sun RPC is provided with no support and without any
811           obligation on the part of Sun Microsystems, Inc. to assist in
812           its use, correction, modification or enhancement.
814           SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT
815           TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY
816           PATENTS BY SUN RPC OR ANY PART THEREOF.
818           In no event will Sun Microsystems, Inc. be liable for any
819           lost revenue or profits or other special, indirect and
820           consequential damages, even if Sun has been advised of the
821           possibility of such damages.
823                Sun Microsystems, Inc.
824                2550 Garcia Avenue
825                Mountain View, California  94043
827    * The port to SGI machines running Irix 4 (`mips-sgi-irix4') was
828      contributed by Tom Quinn.
830    * The port of the Mach and Hurd code to the MIPS architecture
831      (`mips-ANYTHING-gnu') was contribued by Kazumoto Kojima.