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