]>
Commit | Line | Data |
---|---|---|
28f540f4 RM |
1 | Library Maintenance |
2 | ******************* | |
3 | ||
4 | How to Install the GNU C Library | |
5 | ================================ | |
6 | ||
7 | Installation of the GNU C library is relatively simple. | |
8 | ||
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.* | |
12 | ||
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. | |
23 | ||
24 | The GNU C Library currently supports configurations that match the | |
25 | following patterns: | |
26 | ||
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 | |
49 | ||
50 | While no other configurations are supported, there are handy aliases | |
51 | for these few. (These aliases work in other GNU software as well.) | |
52 | ||
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 | |
63 | ||
64 | Here are some options that you should specify (if appropriate) when | |
65 | you run `configure': | |
66 | ||
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. | |
73 | ||
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'. | |
78 | ||
79 | `--nfp' | |
80 | Use this option if your computer lacks hardware floating point | |
81 | support. | |
82 | ||
83 | `--prefix=DIRECTORY' | |
84 | Install machine-independent data files in subdirectories of | |
85 | `DIRECTORY'. (You can also set this in `configparms'; see below.) | |
86 | ||
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.) | |
91 | ||
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. | |
95 | ||
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: | |
99 | ||
100 | mkdir sun4 | |
101 | cd sun4 | |
102 | ../configure sparc-sun-sunos4.1 | |
103 | ||
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. | |
109 | ||
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. | |
115 | ||
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. | |
119 | ||
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. | |
129 | ||
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. | |
139 | ||
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.) | |
143 | ||
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. | |
155 | ||
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. | |
164 | ||
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. | |
170 | ||
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. | |
175 | ||
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. | |
180 | ||
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'. | |
184 | ||
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'. | |
189 | ||
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. | |
194 | ||
195 | Reporting Bugs | |
196 | ============== | |
197 | ||
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. | |
202 | ||
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. | |
209 | ||
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. | |
214 | ||
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'. | |
222 | ||
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! | |
226 | ||
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. | |
230 | ||
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'. | |
238 | ||
239 | Adding New Functions | |
240 | ==================== | |
241 | ||
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. | |
247 | ||
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. | |
251 | ||
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: | |
255 | ||
256 | include ../Rules | |
257 | ||
258 | The basic variables that a subdirectory makefile defines are: | |
259 | ||
260 | `subdir' | |
261 | The name of the subdirectory, for example `stdio'. This variable | |
262 | *must* be defined. | |
263 | ||
264 | `headers' | |
265 | The names of the header files in this section of the library, such | |
266 | as `stdio.h'. | |
267 | ||
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. | |
277 | ||
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'. | |
287 | ||
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'. | |
293 | ||
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'. | |
304 | ||
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. | |
311 | ||
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. | |
316 | ||
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'. | |
324 | ||
325 | Porting the GNU C Library | |
326 | ========================= | |
327 | ||
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. | |
334 | ||
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::.). | |
339 | ||
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 | |
356 | ||
357 | and `unix/Implies' contains: | |
358 | posix | |
359 | ||
360 | So the final list is `unix/bsd/vax unix/bsd unix/inet unix posix'. | |
361 | ||
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::. | |
372 | ||
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). | |
377 | ||
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. | |
385 | ||
386 | There are a few special files that may exist in each subdirectory of | |
387 | `sysdeps': | |
388 | ||
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. | |
402 | ||
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: | |
407 | ||
408 | sysdep-routines := $(sysdep-routines) foo bar | |
409 | ||
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'. | |
416 | ||
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. | |
423 | ||
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. | |
433 | ||
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. | |
440 | ||
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'. | |
450 | ||
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. | |
461 | ||
462 | That is the general system for how system-dependencies are isolated. | |
463 | ||
464 | Layout of the `sysdeps' Directory Hierarchy | |
465 | ------------------------------------------- | |
466 | ||
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. | |
486 | ||
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): | |
490 | ||
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 | |
539 | ||
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'. | |
548 | ||
549 | There are a few directories at the top level of the `sysdeps' | |
550 | hierarchy that are not for particular machine architectures. | |
551 | ||
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. | |
557 | ||
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'. | |
564 | ||
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. | |
571 | ||
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': | |
576 | ||
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'. | |
581 | ||
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'. | |
586 | ||
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'. | |
593 | ||
594 | Porting the GNU C Library to Unix Systems | |
595 | ----------------------------------------- | |
596 | ||
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. | |
602 | ||
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. | |
606 | ||
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. | |
612 | ||
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. | |
619 | ||
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). | |
628 | ||
629 | Contributors to the GNU C Library | |
630 | ================================= | |
631 | ||
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. | |
635 | ||
636 | * The `getopt' function and related code were written by Richard | |
637 | Stallman, David J. MacKenzie, and Roland McGrath. | |
638 | ||
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. | |
644 | ||
645 | All code incorporated from 4.4 BSD is under the following | |
646 | copyright: | |
647 | ||
648 | Copyright (C) 1991 Regents of the University of California. | |
649 | All rights reserved. | |
650 | ||
651 | Redistribution and use in source and binary forms, with or | |
652 | without modification, are permitted provided that the | |
653 | following conditions are met: | |
654 | ||
655 | 1. Redistributions of source code must retain the above | |
656 | copyright notice, this list of conditions and the | |
657 | following disclaimer. | |
658 | ||
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. | |
663 | ||
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. | |
669 | ||
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. | |
674 | ||
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. | |
688 | ||
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. | |
696 | ||
697 | * The merge sort function `qsort' was written by Michael J. Haertel. | |
698 | ||
699 | * The quick sort function used as a fallback by `qsort' was written | |
700 | by Douglas C. Schmidt. | |
701 | ||
702 | * The memory allocation functions `malloc', `realloc' and `free' and | |
703 | related code were written by Michael J. Haertel. | |
704 | ||
705 | * Fast implementations of many of the string functions (`memcpy', | |
706 | `strlen', etc.) were written by Torbjorn Granlund. | |
707 | ||
708 | * Some of the support code for Mach is taken from Mach 3.0 by CMU, | |
709 | and is under the following copyright terms: | |
710 | ||
711 | Mach Operating System | |
712 | Copyright (C) 1991,1990,1989 Carnegie Mellon University | |
713 | All Rights Reserved. | |
714 | ||
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. | |
721 | ||
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. | |
726 | ||
727 | Carnegie Mellon requests users of this software to return to | |
728 | ||
729 | Software Distribution Coordinator | |
730 | School of Computer Science | |
731 | Carnegie Mellon University | |
732 | Pittsburgh PA 15213-3890 | |
733 | ||
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. | |
737 | ||
738 | * The `tar.h' header file was written by David J. MacKenzie. | |
739 | ||
740 | * The port to the MIPS DECStation running Ultrix 4 | |
741 | (`mips-dec-ultrix4') was contributed by Brendan Kehoe and Ian | |
742 | Lance Taylor. | |
743 | ||
744 | * The DES encryption function `crypt' and related functions were | |
745 | contributed by Michael Glad. | |
746 | ||
747 | * The `ftw' function was contributed by Ian Lance Taylor. | |
748 | ||
749 | * The code to support SunOS shared libraries was contributed by Tom | |
750 | Quinn. | |
751 | ||
752 | * The `mktime' function was contributed by Noel Cragg. | |
753 | ||
754 | * The port to the Sequent Symmetry running Dynix version 3 | |
755 | (`i386-sequent-bsd') was contributed by Jason Merrill. | |
756 | ||
757 | * The timezone support code is derived from the public-domain | |
758 | timezone package by Arthur David Olson. | |
759 | ||
760 | * The Internet resolver code is taken directly from BIND 4.9.1, | |
761 | which is under both the Berkeley copyright above and also: | |
762 | ||
763 | Portions Copyright (C) 1993 by Digital Equipment Corporation. | |
764 | ||
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. | |
772 | ||
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. | |
782 | ||
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. | |
786 | ||
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. | |
791 | ||
792 | * The code to support Sun RPC is taken verbatim from Sun's | |
793 | RPCSRC-4.0 distribution, and is covered by this copyright: | |
794 | ||
795 | Copyright (C) 1984, Sun Microsystems, Inc. | |
796 | ||
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. | |
804 | ||
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. | |
809 | ||
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. | |
813 | ||
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. | |
817 | ||
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. | |
822 | ||
823 | Sun Microsystems, Inc. | |
824 | 2550 Garcia Avenue | |
825 | Mountain View, California 94043 | |
826 | ||
827 | * The port to SGI machines running Irix 4 (`mips-sgi-irix4') was | |
828 | contributed by Tom Quinn. | |
829 | ||
830 | * The port of the Mach and Hurd code to the MIPS architecture | |
831 | (`mips-ANYTHING-gnu') was contribued by Kazumoto Kojima. | |
832 |