0aff869a21b1be434f01727881506f4ca8847113
[kopensolaris-gnu/glibc.git] / manual / maint.texi
1 @c \input /gd/gnu/doc/texinfo
2 @c This is for making the `INSTALL' file for the distribution.
3 @c Makeinfo ignores it when processing the file from the include.
4 @setfilename INSTALL
5
6 @node Maintenance, Copying, Library Summary, Top
7 @appendix Library Maintenance
8
9 @menu
10 * Installation::          How to configure, compile and
11                              install the GNU C library.
12 * Reporting Bugs::        How to report bugs (if you want to
13                              get them fixed) and other troubles
14                              you may have with the GNU C library.
15 * Source Layout::         How to add new functions or header files
16                              to the GNU C library.
17 * Porting::               How to port the GNU C library to
18                              a new machine or operating system.
19 * Contributors::          Contributors to the GNU C Library.
20 @end menu
21
22 @node Installation
23 @appendixsec How to Install the GNU C Library
24 @cindex installing the library
25
26 Installation of the GNU C library is relatively simple.
27
28 You need the latest version of GNU @code{make}.  Modifying the GNU C
29 Library to work with other @code{make} programs would be so hard that we
30 recommend you port GNU @code{make} instead.  @strong{Really.}@refill
31
32 To configure the GNU C library for your system, run the shell script
33 @file{configure} with @code{sh}.  Use an argument which is the
34 conventional GNU name for your system configuration---for example,
35 @samp{sparc-sun-sunos4.1}, for a Sun 4 running Sunos 4.1.
36 @xref{Installation, Installation, Installing GNU CC, gcc.info, Using and
37 Porting GNU CC}, for a full description of standard GNU configuration
38 names.
39
40 The GNU C Library currently supports configurations that match the
41 following patterns:
42
43 @example
44 sparc-sun-sunos4.@var{n}
45 m68k-hp-bsd4.3
46 m68k-sun-sunos4.@var{n}
47 m68k-sony-bsd4.3
48 mips-dec-ultrix4.@var{n}
49 i386-bsd4.3
50 i386-sysv
51 i386-sysv4
52 @end example
53
54 While no other configurations are supported, there are handy aliases for
55 these few.  (These aliases work in other GNU software as well.)
56
57 @example
58 sun4-sunos4.@var{n}
59 hp320-bsd4.3
60 sun3-sunos4.@var{n}
61 news
62 decstation-ultrix
63 i386-svr4
64 @end example
65
66 Here are some options that you should specify (if appropriate) when
67 you run @code{configure}:
68
69 @table @samp
70 @item --with-gnu-ld
71 Use this option if you plan to use GNU @code{ld} to link programs with
72 the GNU C Library.  (We strongly recommend that you do.)
73
74 @item --with-gnu-as
75 Use this option if you plan to use the GNU assembler, @code{gas}, when
76 building the GNU C Library.  On some systems, the library may not build
77 properly if you do @emph{not} use @code{gas}.
78
79 @c extra blank line makes it look better
80 @item --nfp
81
82 Use this option if your computer lacks hardware floating point support.
83
84 @item --prefix=@var{directory}
85 Install machine-independent data files in subdirectories of
86 @file{@var{directory}}.  (You can also set this in @file{configparms};
87 see below.)
88
89 @item --exec_prefix=@var{directory}
90 Install the library and other machine-dependent files in subdirectories
91 of @file{@var{directory}}.  (You can also set this in
92 @file{configparms}; see below.)
93 @end table
94
95 The simplest way to run @code{configure} is to do it in the directory
96 that contains the library sources.  This prepares to build the library
97 in that very directory.
98
99 You can prepare to build the library in some other directory by going
100 to that other directory to run @code{configure}.  In order to run
101 configure, you will have to specify a directory for it, like this:
102
103 @example
104 mkdir ../hp320
105 cd ../hp320
106 ../src/configure hp320-bsd4.3
107 @end example
108
109 @noindent
110 @code{configure} looks for the sources in whatever directory you
111 specified for finding @code{configure} itself.  It does not matter where
112 in the file system the source and build directories are---as long as you
113 specify the source directory when you run @code{configure}, you will get
114 the proper results.
115
116 This feature lets you keep sources and binaries in different
117 directories, and that makes it easy to build the library for several
118 different machines from the same set of sources.  Simply create a 
119 build directory for each target machine, and run @code{configure} in
120 that directory specifying the target machine's configuration name.
121
122 The library has a number of special-purpose configuration parameters.
123 These are defined in the file @file{Makeconfig}; see the comments in
124 that file for the details.
125
126 But don't edit the file @file{Makeconfig} yourself---instead, create a
127 file @file{configparms} in the directory where you are building the
128 library, and define in that file the parameters you want to specify.
129 @file{configparms} should @strong{not} be an edited copy of
130 @file{Makeconfig}; specify only the parameters that you want to
131 override.
132
133 Some of the machine-dependent code for some machines uses extensions in
134 the GNU C compiler, so you may need to compile the library with GCC.
135 (In fact, all of the existing complete ports require GCC.)
136
137 To build the library and header files, type @code{make}.  This will
138 produce a lot of output, some of which looks like errors from
139 @code{make} (but isn't).  Look for error messages from @code{make}
140 containing @samp{***}.  Those indicate that something is really wrong.
141 Using the @samp{-w} option to @code{make} may make the output easier to
142 understand (this option tells @code{make} to print messages telling you
143 what subdirectories it is working on).@refill
144
145 To install the library and header files, type @code{make install}, after
146 setting the installation directories in @file{configparms}.  This will
147 build things if necessary, before installing them.@refill
148
149 @node Reporting Bugs
150 @appendixsec Reporting Bugs
151 @cindex reporting bugs
152
153 There are probably bugs in the GNU C library.  If you report them,
154 they will get fixed.  If you don't, no one will ever know about them
155 and they will remain unfixed for all eternity, if not longer.
156
157 To report a bug, first you must find it.  Hopefully, this will be the
158 hard part.  Once you've found a bug, make sure it's really a bug.  A
159 good way to do this is to see if the GNU C library behaves the same way
160 some other C library does.  If so, probably you are wrong and the
161 libraries are right (but not necessarily).  If not, one of the libraries
162 is probably wrong.
163
164 Once you're sure you've found a bug, try to narrow it down to the
165 smallest test case that reproduces the problem.  In the case of a C
166 library, you really only need to narrow it down to one library
167 function call, if possible.  This should not be too difficult.
168
169 The final step when you have a simple test case is to report the
170 bug.  When reporting a bug, send your test case, the results you
171 got, the results you expected, what you think the problem might be
172 (if you've thought of anything), your system type, and the version
173 of the GNU C library which you are using.
174
175 @ignore @c this makes no sense for `INSTALL' before the manual is out. --rm
176 If you are not sure how a function should behave, and this manual
177 doesn't tell you, that's a bug in the manual.  Report that too!
178 If the function's behavior disagrees with the manual, then either the
179 library or the manual has a bug, so report the disagreement.
180 @end ignore
181
182 If you think you have found some way in which the GNU C library does not
183 conform to the ANSI and POSIX standards (@pxref{Standards and
184 Portability}), that is definitely a bug.  Report it!@refill
185
186 Send bug reports to the Internet address
187 @samp{bug-glibc@@prep.ai.mit.edu} or the UUCP path
188 @samp{mit-eddie!prep.ai.mit.edu!bug-glibc}.  If you have other problems
189 with installation, use, or the documentation, please report those as
190 well.@refill
191
192 @node Source Layout
193 @appendixsec Adding New Functions
194
195 The process of building the library is driven by the makefiles, which
196 make heavy use of special features of GNU @code{make}.  The makefiles
197 are very complex, and you probably don't want to try to understand them.
198 But what they do is fairly straightforward, and only requires that you
199 define a few variables in the right places.
200
201 The library sources are divided into subdirectories, grouped by topic.
202 The @file{string} subdirectory has all the string-manipulation
203 functions, @file{stdio} has all the standard I/O functions, etc.
204
205 Each subdirectory contains a simple makefile, called @file{Makefile},
206 which defines a few @code{make} variables and then includes the global
207 makefile @file{Rules} with a line like:
208
209 @example
210 include ../Rules
211 @end example
212
213 @noindent
214 The basic variables that a subdirectory makefile defines are:
215
216 @table @code
217 @item subdir
218 The name of the subdirectory, for example @file{stdio}.
219 This variable @strong{must} be defined.
220
221 @item headers
222 The names of the header files in this section of the library,
223 such as @file{stdio.h}.
224
225 @item routines
226 @itemx aux
227 The names of the modules (source files) in this section of the library.
228 These should be simple names, such as @samp{strlen} (rather than
229 complete file names, such as @file{strlen.c}).  Use @code{routines} for
230 modules that define functions in the library, and @code{aux} for
231 auxiliary modules containing things like data definitions.  But the
232 values of @code{routines} and @code{aux} are just concatenated, so there
233 really is no practical difference.@refill
234
235 @item tests
236 The names of test programs for this section of the library.  These
237 should be simple names, such as @samp{tester} (rather than complete file
238 names, such as @file{tester.c}).  @w{@samp{make tests}} will build and
239 run all the test programs.  If a test program needs input, put the test
240 data in a file called @file{@var{test-program}.input}; it will be given to
241 the test program on its standard input.  If a test program wants to be
242 run with arguments, put the arguments (all on a single line) in a file
243 called @file{@var{test-program}.args}.@refill
244
245 @item others
246 The names of ``other'' programs associated with this section of the
247 library.  These are programs which are not tests per se, but are other
248 small programs included with the library.  They are built by
249 @w{@samp{make others}}.@refill
250
251 @item install-lib
252 @itemx install-data
253 @itemx install
254 Files to be installed by @w{@samp{make install}}.  Things listed in
255 @samp{install-lib} are installed in the directory specified by
256 @samp{libdir} in @file{Makeconfig} (@pxref{Installation}).  Files listed
257 in @code{install-data} are installed in the directory specified by
258 @samp{datadir} in @file{configparms} or @file{Makeconfig}.  Files listed
259 in @code{install} are installed in the directory specified by
260 @samp{bindir} in @file{Makeconfig}.@refill
261
262 @item distribute
263 Other files from this subdirectory which should be put into a
264 distribution tar file.  You need not list here the makefile itself or
265 the source and header files listed in the other standard variables.
266 Only define @code{distribute} if there are files used in an unusual way
267 that should go into the distribution.
268 @end table
269
270 @node Porting
271 @appendixsec Porting the GNU C Library
272
273 The GNU C library is written to be easily portable to a variety of
274 machines and operating systems.  Machine- and operating system-dependent
275 functions are well separated to make it easy to add implementations for
276 new machines or operating systems.  This section describes the layout of
277 the library source tree and explains the mechanisms used to select
278 machine-dependent code to use.
279
280 All the machine-dependent and operating system-dependent files in the
281 library are in the subdirectory @file{sysdeps} under the top-level
282 library source directory.  This directory contains a hierarchy of
283 subdirectories (@pxref{Hierarchy Conventions}).
284
285 Each subdirectory of @file{sysdeps} contains source files for a
286 particular machine or operating system, or for a class of machine or
287 operating system (for example, systems by a particular vendor, or all
288 machines that use IEEE 754 floating-point format).  A configuration
289 specifies an ordered list of these subdirectories.  Each subdirectory
290 implicitly appends its parent directory to the list.  For example,
291 specifying the list @file{unix/bsd/vax} is equivalent to specifying the
292 list @file{unix/bsd/vax unix/bsd unix}.  A subdirectory can also specify
293 that it implies other subdirectories which are not directly above it in
294 the directory hierarchy.  If the file @file{Implies} exists in a
295 subdirectory, it lists other subdirectories of @file{sysdeps} which are
296 appended to the list, appearing after the subdirectory containing the
297 @file{Implies} file.  Lines in an @file{Implies} file that begin with a
298 @samp{#} character are ignored as comments.  For example,
299 @file{unix/bsd/Implies} contains:@refill
300 @example
301 # BSD has Internet-related things.
302 unix/inet
303 @end example
304 @noindent
305 and @file{unix/Implies} contains:
306 @example
307 posix
308 @end example
309
310 @noindent
311 So the final list is @file{unix/bsd/vax unix/bsd vax unix/inet unix posix}.
312
313 @file{sysdeps} has two ``special'' subdirectories, called @file{generic}
314 and @file{stub}.  These two are always implicitly appended to the list
315 of subdirectories (in that order), so you needn't put them in an
316 @file{Implies} file, and you should not create any subdirectories under
317 them.  @file{generic} is for things that can be implemented in
318 machine-independent C, using only other machine-independent functions in
319 the C library.  @file{stub} is for @dfn{stub} versions of functions
320 which cannot be implemented on a particular machine or operating system.
321 The stub functions always return an error, and set @code{errno} to
322 @code{ENOSYS} (Function not implemented).  @xref{Error Reporting}.
323
324 A source file is known to be system-dependent by its having a version in
325 @file{generic} or @file{stub}; every system-dependent function should
326 have either a generic or stub implementation (there is no point in
327 having both).
328
329 If you come across a file that is in one of the main source directories
330 (@file{string}, @file{stdio}, etc.), and you want to write a machine- or
331 operating system-dependent version of it, move the file into
332 @file{sysdeps/generic} and write your new implementation in the
333 appropriate system-specific subdirectory.  Note that if a file is to be
334 system-dependent, it @strong{must not} appear in one of the main source
335 directories.@refill
336
337 There are a few special files that may exist in each subdirectory of
338 @file{sysdeps}:
339
340 @table @file
341 @item Makefile
342 A makefile for this machine or operating system, or class of machine or
343 operating system.  This file is included by the library makefile
344 @file{Makerules}, which is used by the top-level makefile and the
345 subdirectory makefiles.  It can change the variables set in the
346 including makefile or add new rules.  It can use GNU @code{make}
347 conditional directives based on the variable @samp{subdir} (see above) to
348 select different sets of variables and rules for different sections of
349 the library.  It can also set the @code{make} variable
350 @samp{sysdep-routines}, to specify extra modules to be included in the
351 library.  You should use @samp{sysdep-routines} rather than adding
352 modules to @samp{routines} because the latter is used in determining
353 what to distribute for each subdirectory of the main source tree.@refill
354
355 Each makefile in a subdirectory in the ordered list of subdirectories to
356 be searched is included in order.  Since several system-dependent
357 makefiles may be included, each should append to @samp{sysdep-routines}
358 rather than simply setting it:
359
360 @example
361 sysdep-routines := $(sysdep-routines) foo bar
362 @end example
363
364 @item Subdirs
365 This file contains the names of new whole subdirectories under the
366 top-level library source tree that should be included for this system.
367 These subdirectories are treated just like the system-independent
368 subdirectories in the library source tree, such as @file{stdio} and
369 @file{math}.
370
371 Use this when there are whole new sets of routines and header files that
372 should go into the library for the system this subdirectory of
373 @file{sysdeps} implements.  For example,
374 @file{sysdeps/unix/inet/Subdirs} contains @file{inet}; the @file{inet}
375 directory contains various network-oriented operations which only make
376 sense to put in the library on systems that support the Internet.@refill
377
378 @item Dist
379 This file contains the names of files (relative the the subdirectory of
380 @file{sysdeps} in which it appears) which should be included in the
381 distribution.  List any new files used by rules in the @file{Makefile}
382 in the same directory, or header files used by the source files in that
383 directory.  You don't need to list files that are implementations
384 (either C or assembly source) of routines whose names are given in the
385 machine-independent makefiles in the main source tree.
386 @end table
387
388 That is the general system for how system-dependencies are isolated.
389 @iftex
390 The next section explains how to decide what directories in
391 @file{sysdeps} to use.  @ref{Porting to Unix}, has some tips on porting
392 the library to Unix variants.
393 @end iftex
394
395 @menu
396 * Hierarchy Conventions::       The layout of the @file{sysdeps} hierarchy.
397 * Porting to Unix::             Porting the library to an average
398                                    Unix-like system.
399 @end menu
400
401 @node Hierarchy Conventions
402 @appendixsubsec The Layout of the @file{sysdeps} Directory Hierarchy
403
404 A GNU configuration name has three parts: the CPU type, the
405 manufacturer's name, and the operating system.  @file{configure} uses
406 these to pick the list of system-dependent directories to look for.  If
407 the @samp{--nfp} option is @emph{not} passed to @file{configure}, the
408 directory @file{@var{machine}/fpu} is also used.  The operating system
409 often has a @dfn{base operating system}; for example, if the operating
410 system is @samp{sunos4.1}, the base operating system is @samp{unix/bsd}.
411 The algorithm used to pick the list of directories is simple:
412 @file{configure} makes a list of the base operating system,
413 manufacturer, CPU type, and operating system, in that order.  It then
414 concatenates all these together with slashes in between, to produce a
415 directory name; for example, the configuration @w{@samp{sparc-sun-sunos4.1}}
416 results in @file{unix/bsd/sun/sparc/sunos4.1}.  @file{configure} then
417 tries removing each element of the list in turn, so
418 @file{unix/bsd/sparc} and @file{sun/sparc} are also tried, among others.
419 Since the precise version number of the operating system is often not
420 important, and it would be very inconvenient, for example, to have
421 identical @file{sunos4.1.1} and @file{sunos4.1.2} directories,
422 @file{configure} tries successively less specific operating system names
423 by removing trailing suffixes starting with a period.
424
425 Here is the complete list of directories that would be tried for the
426 configuration @samp{sparc-sun-sunos4.1}:
427
428 @example
429 @group
430 sparc/fpu
431 unix/bsd/sun/sunos4.1/sparc
432 unix/bsd/sun/sunos4.1
433 unix/bsd/sun/sunos4/sparc
434 unix/bsd/sun/sunos4
435 unix/bsd/sun/sparc
436 unix/bsd/sun
437 unix/bsd/sunos4.1/sparc
438 unix/bsd/sunos4.1
439 unix/bsd/sunos4/sparc
440 unix/bsd/sunos4
441 unix/bsd/sparc
442 unix/bsd
443 sun/sunos4.1/sparc
444 sun/sunos4.1
445 sun/sunos4/sparc
446 sun/sunos4
447 sun/sparc
448 sun
449 sunos4.1/sparc
450 sunos4.1
451 sunos4/sparc
452 sunos4
453 sparc
454 @end group
455 @end example
456
457 Different machine architectures are generally at the top level of the
458 @file{sysdeps} directory tree.  For example, @w{@file{sysdeps/sparc}}
459 and @w{@file{sysdeps/m68k}}.  These contain files specific to those
460 machine architectures, but not specific to any particular operating
461 system.  There might be subdirectories for specializations of those
462 architectures, such as @w{@file{sysdeps/m68k/68020}}. Code which is
463 specific to the floating-point coprocessor used with a particular
464 machine should go in @w{@file{sysdeps/@var{machine}/fpu}}.
465
466 There are a few directories at the top level of the @file{sysdeps}
467 hierarchy that are not for particular machine architectures.
468
469 @table @file
470 @item generic
471 @itemx stub
472 As described above (@pxref{Porting}), these are the two subdirectories
473 that every configuration implicitly uses after all others.
474
475 @item ieee754
476 This directory is for code using the IEEE 754 floating-point format,
477 where the C type @code{float} is IEEE 754 single-precision format, and
478 @code{double} is IEEE 754 double-precision format.  Usually this
479 directory is referred to in the @file{Implies} file in a machine
480 architecture-specific directory, such as @file{m68k/Implies}.
481
482 @item posix
483 This directory contains implementations of things in the library in
484 terms of @sc{POSIX.1} functions.  This includes some of the @sc{POSIX.1}
485 functions themselves.  Of course, @sc{POSIX.1} cannot be completely
486 implemented in terms of itself, so a configuration using just
487 @file{posix} cannot be complete.
488
489 @item unix
490 This is the directory for Unix-like things.  See @xref{Porting to Unix}.
491 @file{unix} implies @file{posix}.
492
493 @item mach
494 This is the directory for things based on the Mach microkernel from CMU
495 (including the GNU operating system).  Other basic operating systems
496 (VMS, for example) would have their own directories at the top level of
497 the @file{sysdeps} hierarchy, parallel to @file{unix} and @file{mach}.
498 @end table
499
500 @node Porting to Unix
501 @appendixsubsec Porting the GNU C Library to Unix Systems
502
503 Most Unix systems are fundamentally very similar.  There are variations
504 between different machines, and variations in what facilities are
505 provided by the kernel.  But the interface to the operating system
506 facilities is, for the most part, pretty uniform and simple.
507
508 The code for Unix systems is in the directory @file{unix}, at the top
509 level of the @file{sysdeps} hierarchy.  This directory contains
510 subdirectories (and subdirectory trees) for various Unix variants.
511
512 The functions which are system calls in most Unix systems are
513 implemented in assembly code in files in @file{sysdeps/unix}.  These
514 files are named with a suffix of @samp{.S}; for example,
515 @file{__open.S}.  Files ending in @samp{.S} are run through the C
516 preprocessor before being fed to the assembler.
517
518 These files all use a set of macros that should be defined in
519 @file{sysdep.h}.  The @file{sysdep.h} file in @file{sysdeps/unix}
520 partially defines them; a @file{sysdep.h} file in another directory must
521 finish defining them for the particular machine and operating system
522 variant.  See @file{sysdeps/unix/sysdep.h} and the machine-specific
523 @file{sysdep.h} implementations to see what these macros are and what
524 they should do.@refill
525
526 The system-specific makefile for the @file{unix} directory,
527 @file{sysdeps/unix/Makefile}, gives rules to generate several files from
528 the Unix system you are building the library on (which is assumed to be
529 the target system you are building the library @emph{for}).  All the
530 generated files are put in the directory where the object files are
531 kept; they should not affect the source tree itself.  The files
532 generated are @file{ioctls.h}, @file{errnos.h}, @file{sys/param.h}, and
533 @file{errlist.c} (for the @file{stdio} section of the library).
534
535 @ignore
536 @c This section might be a good idea if it is finished,
537 @c but there's no point including it as it stands. --rms
538 @c @appendixsec Compatibility with Traditional C
539
540 @c ??? This section is really short now.  Want to keep it? --roland
541
542 Although the GNU C library implements the ANSI C library facilities, you
543 @emph{can} use the GNU C library with traditional, ``pre-ANSI'' C
544 compilers.  However, you need to be careful because the content and
545 organization of the GNU C library header files differs from that of
546 traditional C implementations.  This means you may need to make changes
547 to your program in order to get it to compile.
548 @end ignore
549
550 @node Contributors
551 @appendixsec Contributors to the GNU C Library
552
553 The GNU C library was written almost entirely by Roland McGrath.
554 Some parts of the library were contributed by other people.
555
556 @itemize @bullet
557 @item
558 The @code{getopt} function and related code were written by
559 @w{Richard Stallman}, @w{David J. MacKenzie}, and @w{Roland McGrath}.
560
561 @item
562 Most of the math functions are taken from 4.4 BSD; they have been
563 modified only slightly to work with the GNU C library.  The
564 Internet-related code (most of the @file{inet} subdirectory) and several
565 other miscellaneous functions and header files have been included with
566 little or no modification.
567
568 All code incorporated from 4.4 BSD is under the following copyright:
569
570 @quotation
571 @display
572 Copyright @copyright{} 1991 Regents of the University of California.
573 All rights reserved.
574 @end display
575
576 Redistribution and use in source and binary forms, with or without
577 modification, are permitted provided that the following conditions
578 are met:
579
580 @enumerate
581 @item
582 Redistributions of source code must retain the above copyright
583 notice, this list of conditions and the following disclaimer.
584 @item
585 Redistributions in binary form must reproduce the above copyright
586 notice, this list of conditions and the following disclaimer in the
587 documentation and/or other materials provided with the distribution.
588 @item
589 All advertising materials mentioning features or use of this software
590 must display the following acknowledgement:
591 @quotation
592         This product includes software developed by the University of
593         California, Berkeley and its contributors.
594 @end quotation
595 @item
596 Neither the name of the University nor the names of its contributors
597 may be used to endorse or promote products derived from this software
598 without specific prior written permission.
599 @end enumerate
600
601 @sc{this software is provided by the regents and contributors ``as is'' and
602 any express or implied warranties, including, but not limited to, the
603 implied warranties of merchantability and fitness for a particular purpose
604 are disclaimed.  in no event shall the regents or contributors be liable
605 for any direct, indirect, incidental, special, exemplary, or consequential
606 damages (including, but not limited to, procurement of substitute goods
607 or services; loss of use, data, or profits; or business interruption)
608 however caused and on any theory of liability, whether in contract, strict
609 liability, or tort (including negligence or otherwise) arising in any way
610 out of the use of this software, even if advised of the possibility of
611 such damage.}
612 @end quotation
613
614 @item
615 The random number generation functions @code{random}, @code{srandom},
616 @code{setstate} and @code{initstate}, which are also the basis for the
617 @code{rand} and @code{srand} functions, were written by Earl T. Cohen
618 for the University of California at Berkeley and are copyrighted by the
619 Regents of the University of California.  They have undergone minor
620 changes to fit into the GNU C library and to fit the ANSI C standard,
621 but the functional code is Berkeley's.@refill
622
623 @item
624 The merge sort function @code{qsort} was written by Michael J. Haertel.
625
626 @item
627 The quick sort function used as a fallback by @code{qsort} was written
628 by Douglas C. Schmidt.
629
630 @item
631 The memory allocation functions @code{malloc}, @code{realloc} and
632 @code{free} and related code were written by Michael J. Haertel.
633
634 @item
635 Fast implementations of many of the string functions (@code{memcpy},
636 @code{strlen}, etc.) were written by
637 @tex
638 Torbj\"orn
639 @end tex
640 @ifinfo
641 Torbjorn
642 @end ifinfo
643 Granlund.@refill
644
645 @item
646 Some of the support code for Mach is taken from Mach 3.0 by CMU,
647 and is under the following copyright terms:
648
649 @quotation
650 @display
651 Mach Operating System
652 Copyright @copyright{} 1991,1990,1989 Carnegie Mellon University
653 All Rights Reserved.
654 @end display
655
656 Permission to use, copy, modify and distribute this software and its
657 documentation is hereby granted, provided that both the copyright
658 notice and this permission notice appear in all copies of the
659 software, derivative works or modified versions, and any portions
660 thereof, and that both notices appear in supporting documentation.
661
662 @sc{carnegie mellon allows free use of this software in its ``as is''
663 condition.  carnegie mellon disclaims any liability of any kind for
664 any damages whatsoever resulting from the use of this software.}
665
666 Carnegie Mellon requests users of this software to return to
667
668 @display
669  Software Distribution Coordinator
670  School of Computer Science
671  Carnegie Mellon University
672  Pittsburgh PA 15213-3890
673 @end display
674
675 @noindent
676 or @samp{Software.Distribution@@CS.CMU.EDU} any improvements or
677 extensions that they make and grant Carnegie Mellon the rights to
678 redistribute these changes.
679 @end quotation
680
681 @item
682 The @file{tar.h} header file was written by David J. MacKenzie.
683
684 @item
685 The port to the MIPS DECStation running Ultrix 4 was contributed by
686 Brendan Kehoe and Ian Lance Taylor.
687
688 @item
689 The DES encryption function @code{crypt} and related functions were
690 contributed by Michael Glad.
691
692 @item
693 The @code{ftw} function was contributed by Ian Lance Taylor.
694
695 @item
696 The code to support SunOS shared libraries was contributed by Tom Quinn.
697 @end itemize
698
699 @c @bye