forked from lattera/glibc
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathINSTALL
992 lines (817 loc) · 42.8 KB
/
INSTALL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
Library Maintenance
*******************
How to Install the GNU C Library
================================
Installation of the GNU C library is relatively simple, but usually
requires several GNU tools to be installed already.
To configure the GNU C library for your system, run the shell script
`configure' with `sh'. Use an argument which is the conventional GNU
name for your system configuration--for example, `sparc-sun-sunos4.1',
for a Sun 4 running SunOS 4.1. *Note Installation:
(gcc.info)Installation, for a full description of standard GNU
configuration names. If you omit the configuration name, `configure'
will try to guess one for you by inspecting the system it is running
on. It may or may not be able to come up with a guess, and the its
guess might be wrong. `configure' will tell you the canonical name of
the chosen configuration before proceeding.
Here are some options that you should specify (if appropriate) when
you run `configure':
`--with-gnu-ld'
Use this option if you plan to use GNU `ld' to link programs with
the GNU C Library. (We strongly recommend that you do.) This
option enables use of features that exist only in GNU `ld'; so if
you configure for GNU `ld' you must use GNU `ld' *every time* you
link with the GNU C Library, and when building it.
`--with-gnu-as'
Use this option if you plan to use the GNU assembler, `gas', when
building the GNU C Library. On some systems, the library may not
build properly if you do *not* use `gas'.
`--with-gnu-binutils'
This option implies both `--with-gnu-ld' and `--with-gnu-as'. On
systems where GNU tools are the system tools, there is no need to
specify this option. These include GNU, GNU/Linux, and free BSD
systems.
`--without-fp'
`--nfp'
Use this option if your computer lacks hardware floating-point
support.
`--prefix=DIRECTORY'
Install machine-independent data files in subdirectories of
`DIRECTORY'. (You can also set this in `configparms'; see below.)
`--exec-prefix=DIRECTORY'
Install the library and other machine-dependent files in
subdirectories of `DIRECTORY'. (You can also set this in
`configparms'; see below.)
`--enable-shared'
`--disable-shared'
Enable or disable building of an ELF shared library on systems that
support it. The default is to build the shared library on systems
using ELF when the GNU `binutils' are available.
`--enable-profile'
`--disable-profile'
Enable or disable building of the profiled C library, `-lc_p'. The
default is to build the profiled library. You may wish to disable
it if you don't plan to do profiling, because it doubles the build
time of compiling just the unprofiled static library.
`--enable-omitfp'
Enable building a highly-optimized but possibly undebuggable
static C library. This causes the normal static and shared (if
enabled) C libraries to be compiled with maximal optimization,
including the `-fomit-frame-pointer' switch that makes debugging
impossible on many machines, and without debugging information
(which makes the binaries substantially smaller). An additional
static library is compiled with no optimization and full debugging
information, and installed as `-lc_g'.
`--enable-bounded'
`--disable-bounded'
Enable or disable building of the C library with support for bounded
pointers. To do this one need the enhanced version of the GNU CC
with can generate code for bounded pointers. This version of the
C library is necessary to run code which is also compiled using the
enhanced gcc for debugging purposes.
There are two more options:
`--with-gmp'
`--with-gettext'
These options are not of much use for the normal installer of the
GNU libc. Only maintainers need this to get automatic updates of
the files from these packages in the GNU C library source tree.
The simplest way to run `configure' is to do it in the directory
that contains the library sources. This prepares to build the library
in that very directory.
You can prepare to build the library in some other directory by going
to that other directory to run `configure'. In order to run configure,
you will have to specify a directory for it, like this:
mkdir sun4
cd sun4
../configure sparc-sun-sunos4.1
`configure' looks for the sources in whatever directory you specified
for finding `configure' itself. It does not matter where in the file
system the source and build directories are--as long as you specify the
source directory when you run `configure', you will get the proper
results.
This feature lets you keep sources and binaries in different
directories, and that makes it easy to build the library for several
different machines from the same set of sources. Simply create a build
directory for each target machine, and run `configure' in that
directory specifying the target machine's configuration name.
The library has a number of special-purpose configuration parameters.
These are defined in the file `Makeconfig'; see the comments in that
file for the details.
But don't edit the file `Makeconfig' yourself--instead, create a
file `configparms' in the directory where you are building the library,
and define in that file the parameters you want to specify.
`configparms' should *not* be an edited copy of `Makeconfig'; specify
only the parameters that you want to override. To see how to set these
parameters, find the section of `Makeconfig' that says "These are the
configuration variables." Then for each parameter that you want to
change, copy the definition from `Makeconfig' to your new `configparms'
file, and change the value as appropriate for your system.
It is easy to configure the GNU C library for cross-compilation by
setting a few variables in `configparms'. Set `CC' to the
cross-compiler for the target you configured the library for; it is
important to use this same `CC' value when running `configure', like
this: `CC=TARGET-gcc configure TARGET'. Set `BUILD_CC' to the compiler
to use for for programs run on the build system as part of compiling
the library. You may need to set `AR' and `RANLIB' to cross-compiling
versions of `ar' and `ranlib' if the native tools are not configured to
work with object files for the target you configured for.
Some of the machine-dependent code for some machines uses extensions
in the GNU C compiler, so you may need to compile the library with GCC.
(In fact, all of the existing complete ports require GCC.)
To build the library and related programs, type `make'. This will
produce a lot of output, some of which may look like errors from `make'
(but isn't). Look for error messages from `make' containing `***'.
Those indicate that something is really wrong.
To build and run some test programs which exercise some of the
library facilities, type `make check'. This will produce several files
with names like `PROGRAM.out'.
To format the `GNU C Library Reference Manual' for printing, type
`make dvi'.
To install the library and its header files, and the Info files of
the manual, type `make install'. This will build things if necessary,
before installing them.
Recommended Tools to Install the GNU C Library
----------------------------------------------
We recommend installing the following GNU tools before attempting to
build the GNU C library:
* `make' 3.75
You need the latest version of GNU `make'. Modifying the GNU C
Library to work with other `make' programs would be so hard that we
recommend you port GNU `make' instead. *Really.* We recommend
version GNU `make' version 3.75 or later.
* GCC 2.7.2.1
On most platforms, the GNU C library can only be compiled with the
GNU C compiler. We recommend GCC version 2.7.2 or later; earlier
versions may have problems.
* `binutils' 2.7
Using the GNU `binutils' (assembler, linker, and related tools) is
preferable when possible, and they are required to build an ELF
shared C library. We recommend `binutils' version 2.7 or later;
earlier versions are known to have problems or to not support all
architectures.
Supported Configurations
------------------------
The GNU C Library currently supports configurations that match the
following patterns:
alpha-ANYTHING-linux
alpha-ANYTHING-linuxecoff
iX86-ANYTHING-gnu
iX86-ANYTHING-linux
m68k-ANYTHING-linux
mips-ANYTHING-linux
sparc-ANYTHING-linux
powerpc-ANYTHING-linux
Former versions of this library used to support the following
configurations but the current status is unknown:
alpha-dec-osf1
iX86-ANYTHING-bsd4.3
iX86-ANYTHING-isc2.2
iX86-ANYTHING-isc3.N
iX86-ANYTHING-sco3.2
iX86-ANYTHING-sco3.2v4
iX86-ANYTHING-sysv
iX86-ANYTHING-sysv4
iX86-force_cpu386-none
iX86-sequent-bsd
i960-nindy960-none
m68k-hp-bsd4.3
m68k-mvme135-none
m68k-mvme136-none
m68k-sony-newsos3
m68k-sony-newsos4
m68k-sun-sunos4.N
mips-dec-ultrix4.N
mips-sgi-irix4.N
sparc-sun-solaris2.N
sparc-sun-sunos4.N
Each case of `iX86' can be `i386', `i486', `i586', or `i686'. All
of those configurations produce a library that can run on any of these
processors. The library will be optimized for the specified processor,
but will not use instructions not available on all of them.
While no other configurations are supported, there are handy aliases
for these few. (These aliases work in other GNU software as well.)
decstation
hp320-bsd4.3 hp300bsd
i486-gnu
i586-linux
i386-sco
i386-sco3.2v4
i386-sequent-dynix
i386-svr4
news
sun3-sunos4.N sun3
sun4-solaris2.N sun4-sunos5.N
sun4-sunos4.N sun4
Reporting Bugs
==============
There are probably bugs in the GNU C library. There are certainly
errors and omissions in this manual. If you report them, they will get
fixed. If you don't, no one will ever know about them and they will
remain unfixed for all eternity, if not longer.
To report a bug, first you must find it. Hopefully, this will be the
hard part. Once you've found a bug, make sure it's really a bug. A
good way to do this is to see if the GNU C library behaves the same way
some other C library does. If so, probably you are wrong and the
libraries are right (but not necessarily). If not, one of the libraries
is probably wrong.
Once you're sure you've found a bug, try to narrow it down to the
smallest test case that reproduces the problem. In the case of a C
library, you really only need to narrow it down to one library function
call, if possible. This should not be too difficult.
The final step when you have a simple test case is to report the bug.
When reporting a bug, send your test case, the results you got, the
results you expected, what you think the problem might be (if you've
thought of anything), your system type, and the version of the GNU C
library which you are using. Also include the files `config.status'
and `config.make' which are created by running `configure'; they will
be in whatever directory was current when you ran `configure'.
If you think you have found some way in which the GNU C library does
not conform to the ANSI and POSIX standards (*note Standards and
Portability::.), that is definitely a bug. Report it!
Send bug reports to the Internet address `[email protected]'
or the UUCP path `mit-eddie!prep.ai.mit.edu!bug-glibc'. If you have
other problems with installation or use, please report those as well.
If you are not sure how a function should behave, and this manual
doesn't tell you, that's a bug in the manual. Report that too! If the
function's behavior disagrees with the manual, then either the library
or the manual has a bug, so report the disagreement. If you find any
errors or omissions in this manual, please report them to the Internet
address `[email protected]' or the UUCP path
`mit-eddie!prep.ai.mit.edu!bug-glibc-manual'.
Adding New Functions
====================
The process of building the library is driven by the makefiles, which
make heavy use of special features of GNU `make'. The makefiles are
very complex, and you probably don't want to try to understand them.
But what they do is fairly straightforward, and only requires that you
define a few variables in the right places.
The library sources are divided into subdirectories, grouped by
topic.
The `string' subdirectory has all the string-manipulation functions,
`math' has all the mathematical functions, etc.
Each subdirectory contains a simple makefile, called `Makefile',
which defines a few `make' variables and then includes the global
makefile `Rules' with a line like:
include ../Rules
The basic variables that a subdirectory makefile defines are:
`subdir'
The name of the subdirectory, for example `stdio'. This variable
*must* be defined.
`headers'
The names of the header files in this section of the library, such
as `stdio.h'.
`routines'
`aux'
The names of the modules (source files) in this section of the
library. These should be simple names, such as `strlen' (rather
than complete file names, such as `strlen.c'). Use `routines' for
modules that define functions in the library, and `aux' for
auxiliary modules containing things like data definitions. But the
values of `routines' and `aux' are just concatenated, so there
really is no practical difference.
`tests'
The names of test programs for this section of the library. These
should be simple names, such as `tester' (rather than complete file
names, such as `tester.c'). `make tests' will build and run all
the test programs. If a test program needs input, put the test
data in a file called `TEST-PROGRAM.input'; it will be given to
the test program on its standard input. If a test program wants
to be run with arguments, put the arguments (all on a single line)
in a file called `TEST-PROGRAM.args'. Test programs should exit
with zero status when the test passes, and nonzero status when the
test indicates a bug in the library or error in building.
`others'
The names of "other" programs associated with this section of the
library. These are programs which are not tests per se, but are
other small programs included with the library. They are built by
`make others'.
`install-lib'
`install-data'
`install'
Files to be installed by `make install'. Files listed in
`install-lib' are installed in the directory specified by `libdir'
in `configparms' or `Makeconfig' (*note Installation::.). Files
listed in `install-data' are installed in the directory specified
by `datadir' in `configparms' or `Makeconfig'. Files listed in
`install' are installed in the directory specified by `bindir' in
`configparms' or `Makeconfig'.
`distribute'
Other files from this subdirectory which should be put into a
distribution tar file. You need not list here the makefile itself
or the source and header files listed in the other standard
variables. Only define `distribute' if there are files used in an
unusual way that should go into the distribution.
`generated'
Files which are generated by `Makefile' in this subdirectory.
These files will be removed by `make clean', and they will never
go into a distribution.
`extra-objs'
Extra object files which are built by `Makefile' in this
subdirectory. This should be a list of file names like `foo.o';
the files will actually be found in whatever directory object
files are being built in. These files will be removed by
`make clean'. This variable is used for secondary object files
needed to build `others' or `tests'.
Porting the GNU C Library
=========================
The GNU C library is written to be easily portable to a variety of
machines and operating systems. Machine- and operating system-dependent
functions are well separated to make it easy to add implementations for
new machines or operating systems. This section describes the layout of
the library source tree and explains the mechanisms used to select
machine-dependent code to use.
All the machine-dependent and operating system-dependent files in the
library are in the subdirectory `sysdeps' under the top-level library
source directory. This directory contains a hierarchy of
subdirectories (*note Hierarchy Conventions::.).
Each subdirectory of `sysdeps' contains source files for a
particular machine or operating system, or for a class of machine or
operating system (for example, systems by a particular vendor, or all
machines that use IEEE 754 floating-point format). A configuration
specifies an ordered list of these subdirectories. Each subdirectory
implicitly appends its parent directory to the list. For example,
specifying the list `unix/bsd/vax' is equivalent to specifying the list
`unix/bsd/vax unix/bsd unix'. A subdirectory can also specify that it
implies other subdirectories which are not directly above it in the
directory hierarchy. If the file `Implies' exists in a subdirectory,
it lists other subdirectories of `sysdeps' which are appended to the
list, appearing after the subdirectory containing the `Implies' file.
Lines in an `Implies' file that begin with a `#' character are ignored
as comments. For example, `unix/bsd/Implies' contains:
# BSD has Internet-related things.
unix/inet
and `unix/Implies' contains:
posix
So the final list is `unix/bsd/vax unix/bsd unix/inet unix posix'.
`sysdeps' has two "special" subdirectories, called `generic' and
`stub'. These two are always implicitly appended to the list of
subdirectories (in that order), so you needn't put them in an `Implies'
file, and you should not create any subdirectories under them intended
to be new specific categories. `generic' is for things that can be
implemented in machine-independent C, using only other
machine-independent functions in the C library. `stub' is for "stub"
versions of functions which cannot be implemented on a particular
machine or operating system. The stub functions always return an
error, and set `errno' to `ENOSYS' (Function not implemented). *Note
Error Reporting::.
A source file is known to be system-dependent by its having a
version in `generic' or `stub'; every generally-available function whose
implementation is system-dependent in should have either a generic or
stub implementation (there is no point in having both). Some rare
functions are only useful on specific systems and aren't defined at all
on others; these do not appear anywhere in the system-independent
source code or makefiles (including the `generic' and `stub'
directories), only in the system-dependent `Makefile' in the specific
system's subdirectory.
If you come across a file that is in one of the main source
directories (`string', `stdio', etc.), and you want to write a machine-
or operating system-dependent version of it, move the file into
`sysdeps/generic' and write your new implementation in the appropriate
system-specific subdirectory. Note that if a file is to be
system-dependent, it *must not* appear in one of the main source
directories.
There are a few special files that may exist in each subdirectory of
`sysdeps':
`Makefile'
A makefile for this machine or operating system, or class of
machine or operating system. This file is included by the library
makefile `Makerules', which is used by the top-level makefile and
the subdirectory makefiles. It can change the variables set in the
including makefile or add new rules. It can use GNU `make'
conditional directives based on the variable `subdir' (see above)
to select different sets of variables and rules for different
sections of the library. It can also set the `make' variable
`sysdep-routines', to specify extra modules to be included in the
library. You should use `sysdep-routines' rather than adding
modules to `routines' because the latter is used in determining
what to distribute for each subdirectory of the main source tree.
Each makefile in a subdirectory in the ordered list of
subdirectories to be searched is included in order. Since several
system-dependent makefiles may be included, each should append to
`sysdep-routines' rather than simply setting it:
sysdep-routines := $(sysdep-routines) foo bar
`Subdirs'
This file contains the names of new whole subdirectories under the
top-level library source tree that should be included for this
system. These subdirectories are treated just like the
system-independent subdirectories in the library source tree, such
as `stdio' and `math'.
Use this when there are completely new sets of functions and header
files that should go into the library for the system this
subdirectory of `sysdeps' implements. For example,
`sysdeps/unix/inet/Subdirs' contains `inet'; the `inet' directory
contains various network-oriented operations which only make sense
to put in the library on systems that support the Internet.
`Dist'
This file contains the names of files (relative to the
subdirectory of `sysdeps' in which it appears) which should be
included in the distribution. List any new files used by rules in
the `Makefile' in the same directory, or header files used by the
source files in that directory. You don't need to list files that
are implementations (either C or assembly source) of routines
whose names are given in the machine-independent makefiles in the
main source tree.
`configure'
This file is a shell script fragment to be run at configuration
time. The top-level `configure' script uses the shell `.' command
to read the `configure' file in each system-dependent directory
chosen, in order. The `configure' files are often generated from
`configure.in' files using Autoconf.
A system-dependent `configure' script will usually add things to
the shell variables `DEFS' and `config_vars'; see the top-level
`configure' script for details. The script can check for
`--with-PACKAGE' options that were passed to the top-level
`configure'. For an option `--with-PACKAGE=VALUE' `configure'
sets the shell variable `with_PACKAGE' (with any dashes in PACKAGE
converted to underscores) to VALUE; if the option is just
`--with-PACKAGE' (no argument), then it sets `with_PACKAGE' to
`yes'.
`configure.in'
This file is an Autoconf input fragment to be processed into the
file `configure' in this subdirectory. *Note Introduction:
(autoconf.info)Introduction, for a description of Autoconf. You
should write either `configure' or `configure.in', but not both.
The first line of `configure.in' should invoke the `m4' macro
`GLIBC_PROVIDES'. This macro does several `AC_PROVIDE' calls for
Autoconf macros which are used by the top-level `configure'
script; without this, those macros might be invoked again
unnecessarily by Autoconf.
That is the general system for how system-dependencies are isolated.
Layout of the `sysdeps' Directory Hierarchy
-------------------------------------------
A GNU configuration name has three parts: the CPU type, the
manufacturer's name, and the operating system. `configure' uses these
to pick the list of system-dependent directories to look for. If the
`--nfp' option is *not* passed to `configure', the directory
`MACHINE/fpu' is also used. The operating system often has a "base
operating system"; for example, if the operating system is `sunos4.1',
the base operating system is `unix/bsd'. The algorithm used to pick
the list of directories is simple: `configure' makes a list of the base
operating system, manufacturer, CPU type, and operating system, in that
order. It then concatenates all these together with slashes in
between, to produce a directory name; for example, the configuration
`sparc-sun-sunos4.1' results in `unix/bsd/sun/sparc/sunos4.1'.
`configure' then tries removing each element of the list in turn, so
`unix/bsd/sparc' and `sun/sparc' are also tried, among others. Since
the precise version number of the operating system is often not
important, and it would be very inconvenient, for example, to have
identical `sunos4.1.1' and `sunos4.1.2' directories, `configure' tries
successively less specific operating system names by removing trailing
suffixes starting with a period.
As an example, here is the complete list of directories that would be
tried for the configuration `sparc-sun-sunos4.1' (without the `--nfp'
option):
sparc/fpu
unix/bsd/sun/sunos4.1/sparc
unix/bsd/sun/sunos4.1
unix/bsd/sun/sunos4/sparc
unix/bsd/sun/sunos4
unix/bsd/sun/sunos/sparc
unix/bsd/sun/sunos
unix/bsd/sun/sparc
unix/bsd/sun
unix/bsd/sunos4.1/sparc
unix/bsd/sunos4.1
unix/bsd/sunos4/sparc
unix/bsd/sunos4
unix/bsd/sunos/sparc
unix/bsd/sunos
unix/bsd/sparc
unix/bsd
unix/sun/sunos4.1/sparc
unix/sun/sunos4.1
unix/sun/sunos4/sparc
unix/sun/sunos4
unix/sun/sunos/sparc
unix/sun/sunos
unix/sun/sparc
unix/sun
unix/sunos4.1/sparc
unix/sunos4.1
unix/sunos4/sparc
unix/sunos4
unix/sunos/sparc
unix/sunos
unix/sparc
unix
sun/sunos4.1/sparc
sun/sunos4.1
sun/sunos4/sparc
sun/sunos4
sun/sunos/sparc
sun/sunos
sun/sparc
sun
sunos4.1/sparc
sunos4.1
sunos4/sparc
sunos4
sunos/sparc
sunos
sparc
Different machine architectures are conventionally subdirectories at
the top level of the `sysdeps' directory tree. For example,
`sysdeps/sparc' and `sysdeps/m68k'. These contain files specific to
those machine architectures, but not specific to any particular
operating system. There might be subdirectories for specializations of
those architectures, such as `sysdeps/m68k/68020'. Code which is
specific to the floating-point coprocessor used with a particular
machine should go in `sysdeps/MACHINE/fpu'.
There are a few directories at the top level of the `sysdeps'
hierarchy that are not for particular machine architectures.
`generic'
`stub'
As described above (*note Porting::.), these are the two
subdirectories that every configuration implicitly uses after all
others.
`ieee754'
This directory is for code using the IEEE 754 floating-point
format, where the C type `float' is IEEE 754 single-precision
format, and `double' is IEEE 754 double-precision format. Usually
this directory is referred to in the `Implies' file in a machine
architecture-specific directory, such as `m68k/Implies'.
`posix'
This directory contains implementations of things in the library in
terms of POSIX.1 functions. This includes some of the POSIX.1
functions themselves. Of course, POSIX.1 cannot be completely
implemented in terms of itself, so a configuration using just
`posix' cannot be complete.
`unix'
This is the directory for Unix-like things. *Note Porting to
Unix::. `unix' implies `posix'. There are some special-purpose
subdirectories of `unix':
`unix/common'
This directory is for things common to both BSD and System V
release 4. Both `unix/bsd' and `unix/sysv/sysv4' imply
`unix/common'.
`unix/inet'
This directory is for `socket' and related functions on Unix
systems. The `inet' top-level subdirectory is enabled by
`unix/inet/Subdirs'. `unix/common' implies `unix/inet'.
`mach'
This is the directory for things based on the Mach microkernel
from CMU (including the GNU operating system). Other basic
operating systems (VMS, for example) would have their own
directories at the top level of the `sysdeps' hierarchy, parallel
to `unix' and `mach'.
Porting the GNU C Library to Unix Systems
-----------------------------------------
Most Unix systems are fundamentally very similar. There are
variations between different machines, and variations in what
facilities are provided by the kernel. But the interface to the
operating system facilities is, for the most part, pretty uniform and
simple.
The code for Unix systems is in the directory `unix', at the top
level of the `sysdeps' hierarchy. This directory contains
subdirectories (and subdirectory trees) for various Unix variants.
The functions which are system calls in most Unix systems are
automatically generated from the `syscalls.list' files for the appropriate
archirecture. The format of the syscalls.list files is quite easy: only
a few informations are necessary line the system call name, the number of
arguments and such. The files are run through the C preprocessor.
These files all use a set of macros that should be defined in
`sysdep.h'. The `sysdep.h' file in `sysdeps/unix' partially defines
them; a `sysdep.h' file in another directory must finish defining them
for the particular machine and operating system variant. See
`sysdeps/unix/sysdep.h' and the machine-specific `sysdep.h'
implementations to see what these macros are and what they should do.
The system-specific makefile for the `unix' directory (that is, the
file `sysdeps/unix/Makefile') gives rules to generate several files
from the Unix system you are building the library on (which is assumed
to be the target system you are building the library *for*). All the
generated files are put in the directory where the object files are
kept; they should not affect the source tree itself. The files
generated are `ioctls.h', `errnos.h', `sys/param.h', and `errlist.c'
(for the `stdio' section of the library).
Contributors to the GNU C Library
=================================
The GNU C library was written originally by Roland McGrath. Some
parts of the library were contributed or worked on by other people.
* The `getopt' function and related code were written by Richard
Stallman, David J. MacKenzie, and Roland McGrath.
* The merge sort function `qsort' was written by Michael J. Haertel.
* The quick sort function used as a fallback by `qsort' was written
by Douglas C. Schmidt.
* The memory allocation functions `malloc', `realloc' and `free' and
related code were written by Michael J. Haertel.
* Fast implementations of many of the string functions (`memcpy',
`strlen', etc.) were written by Torbjorn Granlund.
* The `tar.h' header file was written by David J. MacKenzie.
* The port to the MIPS DECStation running Ultrix 4
(`mips-dec-ultrix4') was contributed by Brendan Kehoe and Ian
Lance Taylor.
* The DES encryption function `crypt' and related functions were
contributed by Michael Glad.
* The `ftw' function was contributed by Ian Lance Taylor.
* The startup code to support SunOS shared libraries was contributed
by Tom Quinn.
* The `mktime' function was contributed by Paul Eggert.
* The port to the Sequent Symmetry running Dynix version 3
(`i386-sequent-bsd') was contributed by Jason Merrill.
* The timezone support code is derived from the public-domain
timezone package by Arthur David Olson and his many contributors.
* The port to the DEC Alpha running OSF/1 (`alpha-dec-osf1') was
contributed by Brendan Kehoe, using some code written by Roland
McGrath.
* The port to SGI machines running Irix 4 (`mips-sgi-irix4') was
contributed by Tom Quinn.
* The port of the Mach and Hurd code to the MIPS architecture
(`mips-ANYTHING-gnu') was contributed by Kazumoto Kojima.
* The floating-point printing function used by `printf' and friends
and the floating-point reading function used by `scanf', `strtod'
and friends were written by Ulrich Drepper. The multi-precision
integer functions used in those functions are taken from GNU MP,
which was contributed by Torbjorn Granlund.
* The internationalization support in the library, and the support
programs `locale' and `localedef', were written by Ulrich Drepper.
Ulrich Drepper adapted the support code for message catalogs
(`libintl.h', etc.) from the GNU `gettext' package, which he also
wrote. He also contributed the `catgets' support and the entire
suite of multi-byte and wide-character support functions
(`wctype.h', `wchar.h', etc.).
* The implementations of the `nsswitch.conf' mechanism and the files
and DNS backends for it were designed and written by Ulrich
Drepper and Roland McGrath, based on a backend interface defined
by Peter Eriksson.
* The port to Linux i386/ELF (`i386-ANYTHING-linux') was contributed
by Ulrich Drepper, based in large part on work done in Hongjiu
Lu's Linux version of the GNU C Library.
* The port to Linux/m68k (`m68k-ANYTHING-linux') was contributed by
Andreas Schwab.
* Richard Henderson contributed the ELF dynamic linking code and
other support for the Alpha processor.
* David Mosberger-Tang contributed the port to Linux/Alpha
(`alpha-ANYTHING-linux').
* Stephen R. van den Berg contributed a highly-optimized `strstr'
function.
* Ulrich Drepper contributed the `hsearch' and `drand48' families of
functions; reentrant `...`_r'' versions of the `random' family;
System V shared memory and IPC support code; and several
highly-optimized string functions for iX86 processors.
* The math functions are taken from `fdlibm-5.1' by Sun
Microsystems, as modified by J.T. Conklin, Ian Lance Taylor,
Ulrich Drepper, Andreas Schwab, and Roland McGrath.
* The `libio' library used to implement `stdio' functions on some
platforms was written by Per Bothner and modified by Ulrich
Drepper.
* Some of the Internet-related code (most of the `inet'
subdirectory) and several other miscellaneous functions and
header files have been included from 4.4 BSD with little or no
modification.
All code incorporated from 4.4 BSD is under the following
copyright:
Copyright (C) 1991 Regents of the University of California.
All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
following conditions are met:
1. Redistributions of source code must retain the above
copyright notice, this list of conditions and the
following disclaimer.
2. Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other
materials provided with the distribution.
3. All advertising materials mentioning features or use of
this software must display the following acknowledgement:
This product includes software developed by the
University of California, Berkeley and its
contributors.
4. Neither the name of the University nor the names of its
contributors may be used to endorse or promote products
derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS
IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.
* The random number generation functions `random', `srandom',
`setstate' and `initstate', which are also the basis for the
`rand' and `srand' functions, were written by Earl T. Cohen for
the University of California at Berkeley and are copyrighted by the
Regents of the University of California. They have undergone minor
changes to fit into the GNU C library and to fit the ANSI C
standard, but the functional code is Berkeley's.
* The Internet resolver code is taken directly from BIND 4.9.5,
which is under both the Berkeley copyright above and also:
Portions Copyright (C) 1993 by Digital Equipment Corporation.
Permission to use, copy, modify, and distribute this software
for any purpose with or without fee is hereby granted,
provided that the above copyright notice and this permission
notice appear in all copies, and that the name of Digital
Equipment Corporation not be used in advertising or publicity
pertaining to distribution of the document or software
without specific, written prior permission.
THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP.
DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT CORPORATION BE
LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
* The code to support Sun RPC is taken verbatim from Sun's
RPCSRC-4.0 distribution, and is covered by this copyright:
Copyright (C) 1984, Sun Microsystems, Inc.
Sun RPC is a product of Sun Microsystems, Inc. and is
provided for unrestricted use provided that this legend is
included on all tape media and as a part of the software
program in whole or part. Users may copy or modify Sun RPC
without charge, but are not authorized to license or
distribute it to anyone else except as part of a product or
program developed by the user.
SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND
INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND
FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF
DEALING, USAGE OR TRADE PRACTICE.
Sun RPC is provided with no support and without any
obligation on the part of Sun Microsystems, Inc. to assist in
its use, correction, modification or enhancement.
SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT
TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY
PATENTS BY SUN RPC OR ANY PART THEREOF.
In no event will Sun Microsystems, Inc. be liable for any
lost revenue or profits or other special, indirect and
consequential damages, even if Sun has been advised of the
possibility of such damages.
Sun Microsystems, Inc.
2550 Garcia Avenue
Mountain View, California 94043
* Some of the support code for Mach is taken from Mach 3.0 by CMU,
and is under the following copyright terms:
Mach Operating System
Copyright (C) 1991,1990,1989 Carnegie Mellon University
All Rights Reserved.
Permission to use, copy, modify and distribute this software
and its documentation is hereby granted, provided that both
the copyright notice and this permission notice appear in all
copies of the software, derivative works or modified
versions, and any portions thereof, and that both notices
appear in supporting documentation.
CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS
IS" CONDITION. CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF
ANY KIND FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF
THIS SOFTWARE.
Carnegie Mellon requests users of this software to return to
Software Distribution Coordinator
School of Computer Science
Carnegie Mellon University
Pittsburgh PA 15213-3890
or `[email protected]' any improvements or
extensions that they make and grant Carnegie Mellon the
rights to redistribute these changes.
* The `getaddrinfo' function is written by Craig Metz and it has the
following copyright:
The Inner Net License, Version 2.00
===================================
The author(s) grant permission for redistribution and use in source and
binary forms, with or without modification, of the software
and documentation provided that the following conditions are met:
0. If you receive a version of the software that is
specifically labelled as not being for redistribution
(check the version message and/or README), you are not
permitted to redistribute that version of the software in
any way or form.
1. All terms of the all other applicable copyrights and
licenses must be followed.
2. Redistributions of source code must retain the authors'
copyright notice(s), this list of conditions, and the
following disclaimer.
3. Redistributions in binary form must reproduce the authors'
copyright notice(s), this list of conditions, and the
following disclaimer in the documentation and/or other
materials provided with the distribution.
4. All advertising materials mentioning features or use of
this software must display the following acknowledgement
with the name(s) of the authors as specified in the
copyright notice(s) substituted where indicated:
This product includes software developed by <name(s)>, The Inner
Net, and other contributors.
5. Neither the name(s) of the author(s) nor the names of its
contributors may be used to endorse or promote products
derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY ITS AUTHORS AND CONTRIBUTORS ``AS
IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.
If these license terms cause you a real problem, contact the author.