]>
Commit | Line | Data |
---|---|---|
f8cac037 RM |
1 | Frequently Asked Question on GNU C Library |
2 | ||
41f27456 | 3 | As every FAQ this one also tries to answer questions the user might have |
66219c07 | 4 | when using the package. Please make sure you read this before sending |
41f27456 | 5 | questions or bug reports to the maintainers. |
f8cac037 RM |
6 | |
7 | The GNU C Library is very complex. The building process exploits the | |
8 | features available in tools generally available. But many things can | |
9 | only be done using GNU tools. Also the code is sometimes hard to | |
10 | understand because it has to be portable but on the other hand must be | |
11 | fast. But you need not understand the details to use GNU C Library. | |
12 | This will only be necessary if you intend to contribute or change it. | |
13 | ||
41f27456 RM |
14 | If you have any questions you think should be answered in this document, |
15 | please let me know. | |
f8cac037 RM |
16 | |
17 | --drepper@cygnus.com | |
18 | \f | |
19 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
41f27456 | 20 | [Q1] ``What systems does the GNU C Library run on?'' |
f8cac037 | 21 | |
41f27456 | 22 | [Q2] ``What compiler do I need to build GNU libc?'' |
613a76ff | 23 | |
41f27456 | 24 | [Q3] ``When starting make I get only error messages. |
613a76ff RM |
25 | What's wrong?'' |
26 | ||
27 | [Q4] ``After I changed configure.in I get `Autoconf version X.Y. | |
28 | or higher is required for this script'. What can I do?'' | |
29 | ||
30 | [Q5] ``Do I need a special linker or archiver?'' | |
31 | ||
32 | [Q6] ``Do I need some more things to compile GNU C Library?'' | |
33 | ||
78b5ba3e RM |
34 | [Q7] ``When I run `nm -u libc.so' on the produced library I still |
35 | find unresolved symbols? Can this be ok?'' | |
613a76ff | 36 | |
999493cb RM |
37 | [Q8] ``Can I replace the libc on my Linux system with GNU libc?'' |
38 | ||
39 | [Q9] ``I expect GNU libc to be 100% source code compatible with | |
613a76ff RM |
40 | the old Linux based GNU libc. Why isn't it like this?'' |
41 | ||
999493cb | 42 | [Q10] ``Why does getlogin() always return NULL on my Linux box?'' |
78b5ba3e | 43 | |
999493cb | 44 | [Q11] ``Where are the DST_* constants found in <sys/time.h> on many |
66219c07 | 45 | systems?'' |
e6c9a67a RM |
46 | |
47 | [Q12] ``The `gencat' utility cannot process the input which are | |
48 | successfully used on my Linux libc based system. Why?'' | |
ec42724d RM |
49 | |
50 | [Q13] ``How do I configure GNU libc so that the essential libraries | |
51 | like libc.so go into /lib and the other into /usr/lib?'' | |
845dcb57 UD |
52 | |
53 | [Q14] ``When linking with the new libc I get unresolved symbols | |
54 | `crypt' and `setkey'. Why aren't these functions in the | |
55 | libc anymore?'' | |
56 | ||
57 | [Q15] ``What are these `add-ons'?'' | |
c4029823 UD |
58 | |
59 | [Q16] ``When I use GNU libc on my Linux system by linking against | |
60 | to libc.so which comes with glibc all I get is a core dump.'' | |
61 | ||
62 | [Q17] ``Looking through the shared libc file I haven't found the | |
63 | functions `stat', `lstat', `fstat', and `mknod' and while | |
64 | linking on my Linux system I get error messages. How is | |
65 | this supposed to work?'' | |
ba1ffaa1 UD |
66 | |
67 | [Q18] ``The prototypes for `connect', `accept', `getsockopt', | |
68 | `setsockopt', `getsockname', `getpeername', `send', | |
69 | `sendto', and `recvfrom' are different in GNU libc than | |
70 | on any other system I saw. This is a bug, isn't it?'' | |
47707456 UD |
71 | |
72 | [Q19] ``My XXX kernel emulates a floating-point coprocessor for me. | |
73 | Should I enable --with-fp?'' | |
68dbb3a6 UD |
74 | |
75 | [Q20] ``How can I compile gcc 2.7.2.1 from the gcc source code using | |
76 | glibc 2.x? | |
19361cb7 UD |
77 | |
78 | [Q21] ``On Linux I've got problems with the declarations in Linux | |
79 | kernel headers.'' | |
613a76ff RM |
80 | \f |
81 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
41f27456 | 82 | [Q1] ``What systems does the GNU C Library run on?'' |
613a76ff | 83 | |
f8cac037 RM |
84 | [A1] {UD} This is difficult to answer. The file `README' lists the |
85 | architectures GNU libc is known to run *at some time*. This does not | |
86 | mean that it still can be compiled and run on them in the moment. | |
87 | ||
88 | The systems glibc is known to work on in the moment and most probably | |
89 | in the future are: | |
90 | ||
91 | *-*-gnu GNU Hurd | |
ba1ffaa1 UD |
92 | i[3456]86-*-linux-gnu Linux-2.0 on Intel |
93 | m68k-*-linux-gnu Linux-2.0 on Motorola 680x0 | |
94 | alpha-*-linux-gnu Linux-2.0 on DEC Alpha | |
f8cac037 RM |
95 | |
96 | Other Linux platforms are also on the way to be supported but I need | |
97 | some success reports first. | |
98 | ||
99 | If you have a system not listed above (or in the `README' file) and | |
100 | you are really interested in porting it, contact | |
101 | ||
41f27456 | 102 | <bug-glibc@prep.ai.mit.edu> |
f8cac037 RM |
103 | |
104 | ||
105 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
41f27456 | 106 | [Q2] ``What compiler do I need to build GNU libc?'' |
f8cac037 RM |
107 | |
108 | [A2] {UD} It is (almost) impossible to compile GNU C Library using a | |
109 | different compiler than GNU CC. A lot of extensions of GNU CC are | |
110 | used to increase the portability and speed. | |
111 | ||
112 | But this does not mean you have to use GNU CC for using the GNU C | |
113 | Library. In fact you should be able to use the native C compiler | |
114 | because the success only depends on the binutils: the linker and | |
115 | archiver. | |
116 | ||
117 | The GNU CC is found like all other GNU packages on | |
118 | ftp://prep.ai.mit.edu/pub/gnu | |
78b5ba3e | 119 | or better one of the many mirror sites. |
f8cac037 RM |
120 | |
121 | You always should try to use the latest official release. Older | |
122 | versions might not have all the features GNU libc could use. | |
123 | ||
124 | ||
125 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
78b5ba3e | 126 | [Q3] ``When starting `make' I get only errors messages. |
f8cac037 RM |
127 | What's wrong?'' |
128 | ||
129 | [A3] {UD} You definitely need GNU make to translate GNU libc. No | |
130 | other make program has the needed functionality. | |
131 | ||
132 | Versions before 3.74 have bugs which prevent correct execution so you | |
133 | should upgrade to the latest version before starting the compilation. | |
134 | ||
135 | ||
136 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
137 | [Q4] ``After I changed configure.in I get `Autoconf version X.Y. | |
138 | or higher is required for this script'. What can I do?'' | |
139 | ||
140 | [A4] {UD} You have to get the specified autoconf version (or a later) | |
141 | from your favourite mirror of prep.ai.mit.edu. | |
142 | ||
143 | ||
144 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
145 | [Q5] ``Do I need a special linker or archiver?'' | |
146 | ||
0200214b RM |
147 | [A5] {UD} If your native versions are not too buggy you can probably |
148 | work with them. But GNU libc works best with GNU binutils. | |
f8cac037 RM |
149 | |
150 | On systems where the native linker does not support weak symbols you | |
151 | will not get a really ISO C compliant C library. Generally speaking | |
152 | you should use the GNU binutils if they provide at least the same | |
153 | functionality as your system's tools. | |
154 | ||
41f27456 | 155 | Always get the newest release of GNU binutils available. |
78b5ba3e RM |
156 | Older releases are known to have bugs that affect building the GNU C |
157 | Library. | |
41f27456 | 158 | |
f8cac037 RM |
159 | |
160 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
161 | [Q6] ``Do I need some more things to compile GNU C Library?'' | |
162 | ||
163 | [A6] {UD} Yes, there are some more :-). | |
164 | ||
78b5ba3e RM |
165 | * GNU gettext; the GNU libc is internationalized and partly localized. |
166 | For bringing the messages for the different languages in the needed | |
167 | form the tools from the GNU gettext package are necessary. See | |
168 | ftp://prep.ai.mit.edu/pub/gnu or better any mirror site. | |
169 | ||
e6c9a67a | 170 | * lots of diskspace (for i?86-linux this means, e.g., ~70MB). |
f8cac037 RM |
171 | |
172 | You should avoid compiling on a NFS mounted device. This is very | |
173 | slow. | |
174 | ||
e6c9a67a | 175 | * plenty of time (approx 1h for i?86-linux on i586@133 or 2.5h on |
ba1ffaa1 | 176 | i486@66 or 4.5h on i486@33). For Hurd systems times are much higher. |
f8cac037 | 177 | |
78b5ba3e | 178 | If you have some more measurements let me know. |
f8cac037 | 179 | |
0200214b RM |
180 | * When compiling for Linux: |
181 | ||
182 | + the header files of the Linux kernel must be available in the | |
183 | search path of the CPP as <linux/*.h> and <asm/*.h>. | |
184 | ||
78b5ba3e RM |
185 | * Some files depend on special tools. E.g., files ending in .gperf |
186 | need a `gperf' program. The GNU version (part of libg++) is known | |
187 | to work while some vendor versions do not. | |
0200214b | 188 | |
ba1ffaa1 UD |
189 | You should not need these tools unless you change the source files. |
190 | ||
f8cac037 | 191 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
78b5ba3e RM |
192 | [Q7] ``When I run `nm -u libc.so' on the produced library I still |
193 | find unresolved symbols? Can this be ok?'' | |
f8cac037 RM |
194 | |
195 | [A7] {UD} Yes, this is ok. There can be several kinds of unresolved | |
196 | symbols: | |
197 | ||
198 | * magic symbols automatically generated by the linker. Names are | |
0200214b | 199 | often like __start_* and __stop_* |
f8cac037 | 200 | |
78b5ba3e RM |
201 | * symbols starting with _dl_* come from the dynamic linker |
202 | ||
f8cac037 RM |
203 | * symbols resolved by using libgcc.a |
204 | (__udivdi3, __umoddi3, or similar) | |
205 | ||
206 | * weak symbols, which need not be resolved at all | |
207 | (currently fabs among others; this gets resolved if the program | |
208 | is linked against libm, too.) | |
209 | ||
210 | Generally, you should make sure you find a real program which produces | |
41f27456 | 211 | errors while linking before deciding there is a problem. |
f8cac037 RM |
212 | |
213 | ||
214 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
999493cb RM |
215 | [Q8] ``Can I replace the libc on my Linux system with GNU libc?'' |
216 | ||
217 | [A8] {UD} You cannot replace any existing libc for Linux with GNU | |
218 | libc. There are different versions of C libraries and you can run | |
219 | libcs with different major version independently. | |
220 | ||
221 | For Linux there are today two libc versions: | |
222 | libc-4 old a.out libc | |
223 | libc-5 current ELF libc | |
224 | ||
225 | GNU libc will have the major number 6 and therefore you can have this | |
e6c9a67a | 226 | additionally installed. For more information consult documentation for |
999493cb RM |
227 | shared library handling. The Makefiles of GNU libc will automatically |
228 | generate the needed symbolic links which the linker will use. | |
229 | ||
230 | ||
231 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
232 | [Q9] ``I expect GNU libc to be 100% source code compatible with | |
613a76ff RM |
233 | the old Linux based GNU libc. Why isn't it like this?'' |
234 | ||
999493cb | 235 | [A9] {DMT,UD} Not every extension in Linux libc's history was well |
41f27456 RM |
236 | thought-out. In fact it had a lot of problems with standards compliance |
237 | and with cleanliness. With the introduction of a new version number these | |
238 | errors now can be corrected. Here is a list of the known source code | |
239 | incompatibilities: | |
240 | ||
0200214b RM |
241 | * _GNU_SOURCE: glibc does not automatically define _GNU_SOURCE. Thus, |
242 | if a program depends on GNU extensions or some other non-standard | |
243 | functionality, it is necessary to compile it with C compiler option | |
244 | -D_GNU_SOURCE, or better, to put `#define _GNU_SOURCE' at the beginning | |
245 | of your source files, before any C library header files are included. | |
246 | This difference normally manifests itself in the form of missing | |
247 | prototypes and/or data type definitions. Thus, if you get such errors, | |
248 | the first thing you should do is try defining _GNU_SOURCE and see if | |
249 | that makes the problem go away. | |
250 | ||
251 | For more information consult the file `NOTES' part of the GNU C | |
252 | library sources. | |
613a76ff RM |
253 | |
254 | * reboot(): GNU libc sanitizes the interface of reboot() to be more | |
255 | compatible with the interface used on other OSes. In particular, | |
256 | reboot() as implemented in glibc takes just one argument. This argument | |
257 | corresponds to the third argument of the Linux reboot system call. | |
258 | That is, a call of the form reboot(a, b, c) needs to be changed into | |
259 | reboot(c). | |
78b5ba3e RM |
260 | Beside this the header <sys/reboot.h> defines the needed constants |
261 | for the argument. These RB_* constants should be used instead of the | |
262 | cryptic magic numbers. | |
263 | ||
264 | * swapon(): the interface of this function didn't changed, but the | |
265 | prototype is in a separate header file <sys/swap.h>. For the additional | |
5290baf0 | 266 | argument of swapon() you should use the SWAP_* constants from |
78b5ba3e | 267 | <linux/swap.h>, which get defined when <sys/swap.h> is included. |
613a76ff RM |
268 | |
269 | * errno: If a program uses variable "errno", then it _must_ include header | |
270 | file <errno.h>. The old libc often (erroneously) declared this variable | |
271 | implicitly as a side-effect of including other libc header files. glibc | |
272 | is careful to avoid such namespace pollution, which, in turn, means that | |
273 | you really need to include the header files that you depend on. This | |
274 | difference normally manifests itself in the form of the compiler | |
275 | complaining about the references of the undeclared symbol "errno". | |
276 | ||
277 | * Linux-specific syscalls: All Linux system calls now have appropriate | |
278 | library wrappers and corresponding declarations in various header files. | |
279 | This is because the syscall() macro that was traditionally used to | |
280 | work around missing syscall wrappers are inherently non-portable and | |
281 | error-prone. The following tables lists all the new syscall stubs, | |
282 | the header-file declaring their interface and the system call name. | |
283 | ||
284 | syscall name: wrapper name: declaring header file: | |
285 | ------------- ------------- ---------------------- | |
9004bc20 | 286 | bdflush bdflush <sys/kdaemon.h> |
613a76ff RM |
287 | create_module create_module <sys/module.h> |
288 | delete_module delete_module <sys/module.h> | |
289 | get_kernel_syms get_kernel_syms <sys/module.h> | |
290 | init_module init_module <sys/module.h> | |
9004bc20 | 291 | syslog ksyslog_ctl <sys/klog.h> |
f8cac037 | 292 | |
78b5ba3e | 293 | * lpd: Older versions of lpd depend on a routine called _validuser(). |
a1470b6f RM |
294 | The library does not provide this function, but instead provides |
295 | __ivaliduser() which has a slightly different interfaces. Simply | |
78b5ba3e | 296 | upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD |
a1470b6f RM |
297 | lpd is known to be working). |
298 | ||
999493cb RM |
299 | * resolver functions/BIND: like on many other systems the functions of |
300 | the resolver library are not included in the libc itself. There is | |
301 | a separate library libresolv. If you find some symbols starting with | |
302 | `res_*' undefined simply add -lresolv to your call of the linker. | |
303 | ||
5290baf0 UD |
304 | * the `signal' function's behaviour corresponds to the BSD semantic and |
305 | not the SysV semantic as it was in libc-5. The interface on all GNU | |
306 | systems shall be the same and BSD is the semantic of choice. To use | |
307 | the SysV behaviour simply use `sysv_signal'. The major difference is | |
308 | that the SysV implementation sets the SA_ONESHOT flag and so the handler | |
309 | gets removed after the first call. | |
310 | ||
78b5ba3e RM |
311 | |
312 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
999493cb | 313 | [Q10] ``Why does getlogin() always return NULL on my Linux box?'' |
78b5ba3e | 314 | |
999493cb | 315 | [A10] {UD} The GNU C library has a format for the UTMP and WTMP file |
78b5ba3e RM |
316 | which differs from what your system currently has. It was extended to |
317 | fulfill the needs of the next years when IPv6 is introduced. So the | |
318 | record size is different, fields might have a different position and | |
319 | so reading the files written by functions from the one library cannot | |
320 | be read by functions from the other library. Sorry, but this is what | |
321 | a major release is for. It's better to have a cut now than having no | |
322 | means to support the new techniques later. | |
323 | ||
324 | ||
613a76ff | 325 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
999493cb | 326 | [Q11] ``Where are the DST_* constants found in <sys/time.h> on many |
66219c07 RM |
327 | systems?'' |
328 | ||
999493cb | 329 | [A11] {UD} These constants come from the old BSD days and are not used |
66219c07 | 330 | today anymore (even the Linux based glibc does not implement the handling |
999493cb | 331 | although the constants are defined). |
66219c07 RM |
332 | |
333 | Instead GNU libc contains the zone database handling and compatibility | |
334 | code for POSIX TZ environment variable handling. | |
335 | ||
336 | ||
e6c9a67a | 337 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
e6c9a67a RM |
338 | [Q12] ``The `gencat' utility cannot process the input which are |
339 | successfully used on my Linux libc based system. Why?'' | |
340 | ||
341 | [A12] {UD} Unlike the author of the `gencat' program which is distributed | |
342 | with Linux libc I have read the underlying standards before writing the | |
343 | code. It is completely compatible with the specification given in | |
344 | X/Open Portability Guide. | |
345 | ||
346 | To ease the transition from the Linux version some of the non-standard | |
347 | features are also present in the `gencat' program of GNU libc. This | |
348 | mainly includes the use of symbols for the message number and the automatic | |
349 | generation of header files which contain the needed #defines to map the | |
350 | symbols to integers. | |
351 | ||
352 | Here is a simple SED script to convert at least some Linux specific | |
353 | catalog files to the XPG4 form: | |
354 | ||
355 | ----------------------------------------------------------------------- | |
356 | # Change catalog source in Linux specific format to standard XPG format. | |
357 | # Ulrich Drepper <drepper@cygnus.com>, 1996. | |
358 | # | |
359 | /^\$ #/ { | |
360 | h | |
361 | s/\$ #\([^ ]*\).*/\1/ | |
362 | x | |
363 | s/\$ #[^ ]* *\(.*\)/\$ \1/ | |
364 | } | |
365 | ||
366 | /^# / { | |
367 | s/^# \(.*\)/\1/ | |
368 | G | |
369 | s/\(.*\)\n\(.*\)/\2 \1/ | |
370 | } | |
371 | ----------------------------------------------------------------------- | |
372 | ||
373 | ||
ec42724d RM |
374 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
375 | [Q13] ``How do I configure GNU libc so that the essential libraries | |
376 | like libc.so go into /lib and the other into /usr/lib?'' | |
377 | ||
5290baf0 UD |
378 | [A13] {UD,AJ} Like all other GNU packages GNU libc is configured to |
379 | use a base directory and install all files relative to this. If you | |
380 | intend to really use GNU libc on your system this base directory is | |
381 | /usr. I.e., you run | |
ec42724d RM |
382 | configure --prefix=/usr <other_options> |
383 | ||
384 | Some systems like Linux have a filesystem standard which makes a | |
385 | difference between essential libraries and others. Essential | |
386 | libraries are placed in /lib because this directory is required to be | |
387 | located on the same disk partition as /. The /usr subtree might be | |
388 | found on another partition/disk. | |
389 | ||
390 | To install the essential libraries which come with GNU libc in /lib | |
5290baf0 UD |
391 | one must explicitly tell this (except on Linux, see below). Autoconf |
392 | has no option for this so you have to use the file where all user | |
393 | supplied additional information should go in: `configparms' (see the | |
394 | `INSTALL' file). Therefore the `configparms' file should contain: | |
ec42724d RM |
395 | |
396 | slibdir=/lib | |
397 | sysconfdir=/etc | |
398 | ||
399 | The first line specifies the directory for the essential libraries, | |
400 | the second line the directory for file which are by tradition placed | |
401 | in a directory named /etc. | |
402 | ||
5290baf0 UD |
403 | No rule without an exception: If you configure for Linux with |
404 | --prefix=/usr, then slibdir and sysconfdir will automatically be | |
405 | defined as stated above. | |
406 | ||
ec42724d | 407 | |
845dcb57 UD |
408 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
409 | [Q14] ``When linking with the new libc I get unresolved symbols | |
410 | `crypt' and `setkey'. Why aren't these functions in the | |
411 | libc anymore?'' | |
412 | ||
413 | [A14] {UD} Remember the US restrictions of exporting cryptographic | |
414 | programs and source code. Until this law gets abolished we cannot | |
415 | ship the cryptographic function together with the libc. | |
416 | ||
417 | But of course we provide the code and there is an very easy way to use | |
418 | this code. First get the extra package. People in the US way get it | |
419 | from the same place they got the GNU libc from. People outside the US | |
420 | should get the code from ftp.uni-c.dk [129.142.6.74], or another | |
421 | archive site outside the USA. The README explains how to install the | |
422 | sources. | |
423 | ||
424 | If you already have the crypt code on your system the reason for the | |
425 | failure is probably that you failed to link with -lcrypt. The crypto | |
426 | functions are in a separate library to make it possible to export GNU | |
427 | libc binaries from the US. | |
428 | ||
429 | ||
430 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
431 | [Q15] ``What are these `add-ons'?'' | |
432 | ||
ba1ffaa1 | 433 | [A15] {UD} To avoid complications with export rules or external source |
845dcb57 UD |
434 | code some optional parts of the libc are distributed as separate |
435 | packages (e.g., the crypt package, see Q14). | |
436 | ||
437 | To ease the use as part of GNU libc the installer just has to unpack | |
438 | the package and tell the configuration script about these additional | |
439 | subdirectories using the --enable-add-ons option. When you add the | |
440 | crypt add-on you just have to use | |
441 | ||
68dbb3a6 | 442 | configure --enable-add-ons=crypt,XXX ... |
845dcb57 UD |
443 | |
444 | where XXX are possible other add-ons and ... means the rest of the | |
445 | normal option list. | |
446 | ||
447 | You can use add-ons also to overwrite some files in glibc. The add-on | |
448 | system dependent subdirs are search first. It is also possible to add | |
449 | banner files (use a file named `Banner') or create shared libraries. | |
450 | ||
451 | Using add-ons has the big advantage that the makefiles of the GNU libc | |
452 | can be used. Only some few stub rules must be written to get | |
453 | everything running. Even handling of architecture dependent | |
454 | compilation is provided. The GNU libc's sysdeps/ directory shows how | |
455 | to use this feature. | |
456 | ||
457 | ||
c4029823 UD |
458 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
459 | [Q16] ``When I use GNU libc on my Linux system by linking against | |
460 | to libc.so which comes with glibc all I get is a core dump.'' | |
461 | ||
462 | [A16] {UD} It is not enough to simply link against the GNU libc | |
463 | library itself. The GNU C library comes with its own dynamic linker | |
464 | which really conforms to the ELF API standard. This dynamic linker | |
465 | must be used. | |
466 | ||
467 | Normally this is done by the compiler. The gcc will use | |
468 | ||
469 | -dynamic-linker /lib/ld-linux.so.1 | |
470 | ||
471 | unless the user specifies her/himself a -dynamic-linker argument. But | |
472 | this is not the correct name for the GNU dynamic linker. The correct | |
473 | name is /lib/ld.so.1 which is the name specified in the SVr4 ABi. | |
474 | ||
475 | To change your environment to use GNU libc for compiling you need to | |
476 | change the `specs' file of your gcc. This file is normally found at | |
477 | ||
478 | /usr/lib/gcc-lib/<arch>/<version>/specs | |
479 | ||
480 | In this file you have to change a few things: | |
481 | ||
0d204b0a | 482 | - change `ld-linux.so.1' to `ld.so.1' (or to ld-linux.so.2, see below) |
c4029823 UD |
483 | |
484 | - remove all expression `%{...:-lgmon}'; there is no libgmon in glibc | |
485 | ||
486 | ||
487 | Things are getting a bit more complicated if you have GNU libc | |
488 | installed in some other place than /usr, i.e., if you do not want to | |
489 | use it instead of the old libc. In this case the needed startup files | |
490 | and libraries are not found in the regular places. So the specs file | |
491 | must tell the compiler and linker exactly what to use. Here is for | |
492 | example the gcc-2.7.2 specs file when GNU libc is installed at | |
68dbb3a6 | 493 | /usr: |
c4029823 UD |
494 | |
495 | ----------------------------------------------------------------------- | |
496 | *asm: | |
497 | %{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} | |
498 | ||
499 | *asm_final: | |
500 | %{pipe:-} | |
501 | ||
502 | *cpp: | |
68dbb3a6 | 503 | %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} |
c4029823 UD |
504 | |
505 | *cc1: | |
68dbb3a6 | 506 | %{profile:-p} |
c4029823 UD |
507 | |
508 | *cc1plus: | |
509 | ||
510 | ||
511 | *endfile: | |
68dbb3a6 | 512 | %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s |
c4029823 UD |
513 | |
514 | *link: | |
68dbb3a6 | 515 | -m elf_i386 %{shared:-shared} %{!shared: %{!ibcs: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}} %{static:-static}}} |
c4029823 UD |
516 | |
517 | *lib: | |
68dbb3a6 | 518 | %{!shared: %{pthread:-lpthread} %{profile:-lc_p} %{!profile: -lc}} |
c4029823 UD |
519 | |
520 | *libgcc: | |
68dbb3a6 | 521 | -lgcc |
c4029823 UD |
522 | |
523 | *startfile: | |
68dbb3a6 | 524 | %{!shared: %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} %{!p:%{profile:gcrt1.o%s} %{!profile:crt1.o%s}}}} crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s} |
c4029823 UD |
525 | |
526 | *switches_need_spaces: | |
527 | ||
528 | ||
529 | *signed_char: | |
530 | %{funsigned-char:-D__CHAR_UNSIGNED__} | |
531 | ||
532 | *predefines: | |
533 | -D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) | |
534 | ||
535 | *cross_compile: | |
536 | 0 | |
537 | ||
538 | *multilib: | |
539 | . ; | |
540 | ||
541 | ----------------------------------------------------------------------- | |
542 | ||
68dbb3a6 UD |
543 | The above is currently correct for ix86/Linux. Because of |
544 | compatibility issues on this platform the dynamic linker must have | |
545 | a different name: ld-linux.so.2. So you have to replace | |
0d204b0a | 546 | |
0d204b0a | 547 | %{!dynamic-linker:-dynamic-linker=/home/gnu/lib/ld-linux.so.2} |
68dbb3a6 UD |
548 | by |
549 | %{!dynamic-linker:-dynamic-linker=/home/gnu/lib/ld.so.1} | |
0d204b0a | 550 | |
5290baf0 | 551 | in the above example specs file to make it work for other systems. |
0d204b0a | 552 | |
0d8733c4 UD |
553 | Version 2.7.2.2 does and future versions of GCC will automatically |
554 | provide the correct specs. | |
c4029823 UD |
555 | |
556 | ||
557 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
558 | [Q17] ``Looking through the shared libc file I haven't found the | |
559 | functions `stat', `lstat', `fstat', and `mknod' and while | |
560 | linking on my Linux system I get error messages. How is | |
561 | this supposed to work?'' | |
562 | ||
563 | [A17] {RM} Believe it or not, stat and lstat (and fstat, and mknod) | |
564 | are supposed to be undefined references in libc.so.6! Your problem is | |
565 | probably a missing or incorrect /usr/lib/libc.so file; note that this | |
566 | is a small text file now, not a symlink to libc.so.6. It should look | |
567 | something like this: | |
568 | ||
569 | GROUP ( libc.so.6 ld.so.1 libc.a ) | |
570 | ||
571 | ||
ba1ffaa1 UD |
572 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
573 | [Q18] ``The prototypes for `connect', `accept', `getsockopt', | |
574 | `setsockopt', `getsockname', `getpeername', `send', | |
575 | `sendto', and `recvfrom' are different in GNU libc from | |
576 | any other system I saw. This is a bug, isn't it?'' | |
577 | ||
578 | [A18] {UD} No, this is no bug. This version of the GNU libc already | |
579 | follows the to-be-released POSIX.1g standard. In this standard | |
580 | the type `size_t' is used for all parameters which describe a size. | |
581 | So better change now. | |
582 | ||
583 | This change is critical for system which have | |
584 | sizeof (int) != sizeof (size_t) | |
585 | like the Alpha. | |
586 | ||
587 | ||
47707456 UD |
588 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
589 | [Q19] ``My XXX kernel emulates a floating-point coprocessor for me. | |
590 | Should I enable --with-fp?'' | |
591 | ||
592 | [A19] {UD} As `configure --help' shows the default value is `yes' and | |
593 | this should not be changed unless the FPU instructions would be | |
594 | invalid. I.e., an emulated FPU is for the libc as good as a real one. | |
595 | ||
596 | ||
68dbb3a6 UD |
597 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
598 | [Q20] ``How can I compile gcc 2.7.2.1 from the gcc source code using | |
599 | glibc 2.x? | |
600 | ||
0d8733c4 UD |
601 | [A20] {AJ} There's only support for glibc 2.0 in gcc 2.7.2.2 or later. |
602 | For 2.7.2.2 you should use the following patch and configure for | |
603 | e.g. i486-linux. | |
604 | ----------------------------------------------------------------------- | |
605 | --- configure Tue Feb 11 15:57:17 1997 | |
606 | +++ configure Wed Feb 12 23:09:29 1997 | |
607 | @@ -1021,7 +1021,7 @@ | |
608 | gnu_ld=yes | |
609 | # GNU libc version 2 does not supply these; | |
610 | # we want them from GCC. | |
611 | - extra_parts="crtbegin.o crtend.o" | |
5ae9d168 | 612 | + extra_parts="crtbegin.o crtbeginS.o crtend.o crtendS.o" |
0d8733c4 UD |
613 | ;; |
614 | i[3456]86-go32-msdos | i[3456]86-*-go32) | |
615 | cpu_type=i386 | |
616 | ----------------------------------------------------------------------- | |
68dbb3a6 | 617 | |
19361cb7 UD |
618 | |
619 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
620 | [Q21] ``On Linux I've got problems with the declarations in Linux | |
621 | kernel headers.'' | |
622 | ||
623 | [A21] {UD,AJ} On Linux, the use of kernel headers is reduced to a very | |
624 | minimum. Besides giving Linus the possibility to change the headers | |
625 | more freely it has another reason: user level programs now do not | |
626 | always use the same types like the kernel does. | |
627 | ||
628 | I.e., the libc abstracts the use of types. E.g., the sigset_t type is | |
629 | in the kernel 32 or 64 bits wide. In glibc it is 1024 bits wide, in | |
630 | preparation for future development. The reasons are obvious: we don't | |
631 | want to have a new major release when the Linux kernel gets these | |
632 | functionality. Consult the headers for more information about the changes. | |
633 | ||
634 | Therefore you shouldn't include Linux kernel header files directly if | |
635 | glibc has defined a replacement. Otherwise you might get undefined | |
636 | results because of type conflicts. | |
68dbb3a6 UD |
637 | |
638 | ||
66219c07 | 639 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
f8cac037 RM |
640 | \f |
641 | Answers were given by: | |
642 | {UD} Ulrich Drepper, <drepper@cygnus.com> | |
613a76ff | 643 | {DMT} David Mosberger-Tang, <davidm@AZStarNet.com> |
0200214b | 644 | {RM} Roland McGrath, <roland@gnu.ai.mit.edu> |
68dbb3a6 | 645 | {HJL} H.J. Lu, <hjl@gnu.ai.mit.edu> |
5290baf0 | 646 | {AJ} Andreas Jaeger, <aj@arthur.pfalz.de> |
f8cac037 RM |
647 | \f |
648 | Local Variables: | |
649 | mode:text | |
650 | End: |