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