1: Frequently Asked Questions about the GNU C Library 2: 3: This document tries to answer questions a user might have when installing 4: and using glibc. Please make sure you read this before sending questions or 5: bug reports to the maintainers. 6: 7: The GNU C library is very complex. The installation process has not been 8: completely automated; there are too many variables. You can do substantial 9: damage to your system by installing the library incorrectly. Make sure you 10: understand what you are undertaking before you begin. 11: 12: If you have any questions you think should be answered in this document, 13: please let me know. 14: 15: --drepper@redhat.com 16: ^L 17: ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 18: 19: 1. Compiling glibc 20: 21: 1.1. What systems does the GNU C Library run on? 22: 1.2. What compiler do I need to build GNU libc? 23: 1.3. When I try to compile glibc I get only error messages. 24: What's wrong? 25: 1.4. Do I need a special linker or assembler? 26: 1.5. Which compiler should I use for powerpc? 27: 1.6. Which tools should I use for ARM? 28: 1.7. Do I need some more things to compile the GNU C Library? 29: 1.8. What version of the Linux kernel headers should be used? 30: 1.9. The compiler hangs while building iconvdata modules. What's 31: wrong? 32: 1.10. When I run `nm -u libc.so' on the produced library I still 33: find unresolved symbols. Can this be ok? 34: 1.11. What are these `add-ons'? 35: 1.12. My XXX kernel emulates a floating-point coprocessor for me. 36: Should I enable --with-fp? 37: 1.13. When compiling GNU libc I get lots of errors saying functions 38: in glibc are duplicated in libgcc. 39: 1.14. Why do I get messages about missing thread functions when I use 40: librt? I don't even use threads. 41: 1.15. What's the problem with configure --enable-omitfp? 42: 1.16. I get failures during `make check'. What should I do? 43: 1.17. What is symbol versioning good for? Do I need it? 44: 1.18. How can I compile on my fast ix86 machine a working libc for my slow 45: i386? After installing libc, programs abort with "Illegal 46: Instruction". 47: 1.19. `make' complains about a missing dlfcn/libdl.so when building 48: malloc/libmemprof.so. How can I fix this? 49: 1.20. Which tools should I use for MIPS? 50: 1.21. Which compiler should I use for powerpc64? 51: 1.22. `make' fails when running rpcgen the first time, 52: what is going on? How do I fix this? 53: 54: 2. Installation and configuration issues 55: 56: 2.1. Can I replace the libc on my Linux system with GNU libc? 57: 2.2. How do I configure GNU libc so that the essential libraries 58: like libc.so go into /lib and the other into /usr/lib? 59: 2.3. How should I avoid damaging my system when I install GNU libc? 60: 2.4. Do I need to use GNU CC to compile programs that will use the 61: GNU C Library? 62: 2.5. When linking with the new libc I get unresolved symbols 63: `crypt' and `setkey'. Why aren't these functions in the 64: libc anymore? 65: 2.6. When I use GNU libc on my Linux system by linking against 66: the libc.so which comes with glibc all I get is a core dump. 67: 2.7. Looking through the shared libc file I haven't found the 68: functions `stat', `lstat', `fstat', and `mknod' and while 69: linking on my Linux system I get error messages. How is 70: this supposed to work? 71: 2.8. When I run an executable on one system which I compiled on 72: another, I get dynamic linker errors. Both systems have the same 73: version of glibc installed. What's wrong? 74: 2.9. How can I compile gcc 2.7.2.1 from the gcc source code using 75: glibc 2.x? 76: 2.10. The `gencat' utility cannot process the catalog sources which 77: were used on my Linux libc5 based system. Why? 78: 2.11. Programs using libc have their messages translated, but other 79: behavior is not localized (e.g. collating order); why? 80: 2.12. I have set up /etc/nis.conf, and the Linux libc 5 with NYS 81: works great. But the glibc NIS+ doesn't seem to work. 82: 2.13. I have killed ypbind to stop using NIS, but glibc 83: continues using NIS. 84: 2.14. Under Linux/Alpha, I always get "do_ypcall: clnt_call: 85: RPC: Unable to receive; errno = Connection refused" when using NIS. 86: 2.15. After installing glibc name resolving doesn't work properly. 87: 2.16. How do I create the databases for NSS? 88: 2.17. I have /usr/include/net and /usr/include/scsi as symlinks 89: into my Linux source tree. Is that wrong? 90: 2.18. Programs like `logname', `top', `uptime' `users', `w' and 91: `who', show incorrect information about the (number of) 92: users on my system. Why? 93: 2.19. After upgrading to glibc 2.1 with symbol versioning I get 94: errors about undefined symbols. What went wrong? 95: 2.20. When I start the program XXX after upgrading the library 96: I get 97: XXX: Symbol `_sys_errlist' has different size in shared 98: object, consider re-linking 99: Why? What should I do? 100: 2.21. What do I need for C++ development? 101: 2.22. Even statically linked programs need some shared libraries 102: which is not acceptable for me. What can I do? 103: 2.23. I just upgraded my Linux system to glibc and now I get 104: errors whenever I try to link any program. 105: 2.24. When I use nscd the machine freezes. 106: 2.25. I need lots of open files. What do I have to do? 107: 2.26. How do I get the same behavior on parsing /etc/passwd and 108: /etc/group as I have with libc5 ? 109: 2.27. What needs to be recompiled when upgrading from glibc 2.0 to glibc 110: 2.1? 111: 2.28. Why is extracting files via tar so slow? 112: 2.29. Compiling programs I get parse errors in libio.h (e.g. "parse error 113: before `_IO_seekoff'"). How should I fix this? 114: 2.30. After upgrading to glibc 2.1, libraries that were compiled against 115: glibc 2.0.x don't work anymore. 116: 2.31. What happened to the Berkeley DB libraries? Can I still use db 117: in /etc/nsswitch.conf? 118: 2.32. What has do be done when upgrading to glibc 2.2? 119: 2.33. The makefiles want to do a CVS commit. 120: 2.34. When compiling C++ programs, I get a compilation error in streambuf.h. 121: 2.35. When recompiling GCC, I get compilation errors in libio. 122: 2.36. Why shall glibc never get installed on GNU/Linux systems in 123: /usr/local? 124: 2.37. When recompiling GCC, I get compilation errors in libstdc++. 125: 126: 3. Source and binary incompatibilities, and what to do about them 127: 128: 3.1. I expect GNU libc to be 100% source code compatible with 129: the old Linux based GNU libc. Why isn't it like this? 130: 3.2. Why does getlogin() always return NULL on my Linux box? 131: 3.3. Where are the DST_* constants found in <sys/time.h> on many 132: systems? 133: 3.4. The prototypes for `connect', `accept', `getsockopt', 134: `setsockopt', `getsockname', `getpeername', `send', 135: `sendto', and `recvfrom' are different in GNU libc from 136: any other system I saw. This is a bug, isn't it? 137: 3.5. On Linux I've got problems with the declarations in Linux 138: kernel headers. 139: 3.6. I don't include any kernel headers myself but the compiler 140: still complains about redeclarations of types in the kernel 141: headers. 142: 3.7. Why don't signals interrupt system calls anymore? 143: 3.8. I've got errors compiling code that uses certain string 144: functions. Why? 145: 3.9. I get compiler messages "Initializer element not constant" with 146: stdin/stdout/stderr. Why? 147: 3.10. I can't compile with gcc -traditional (or 148: -traditional-cpp). Why? 149: 3.11. I get some errors with `gcc -ansi'. Isn't glibc ANSI compatible? 150: 3.12. I can't access some functions anymore. nm shows that they do 151: exist but linking fails nevertheless. 152: 3.13. When using the db-2 library which comes with glibc is used in 153: the Perl db modules the testsuite is not passed. This did not 154: happen with db-1, gdbm, or ndbm. 155: 3.14. The pow() inline function I get when including <math.h> is broken. 156: I get segmentation faults when I run the program. 157: 3.15. The sys/sem.h file lacks the definition of `union semun'. 158: 3.16. Why has <netinet/ip_fw.h> disappeared? 159: 3.17. I get floods of warnings when I use -Wconversion and include 160: <string.h> or <math.h>. 161: 3.18. After upgrading to glibc 2.1, I receive errors about 162: unresolved symbols, like `_dl_initial_searchlist' and can not 163: execute any binaries. What went wrong? 164: 3.19. bonnie reports that char i/o with glibc 2 is much slower than with 165: libc5. What can be done? 166: 3.20. Programs compiled with glibc 2.1 can't read db files made with glibc 167: 2.0. What has changed that programs like rpm break? 168: 3.21. Autoconf's AC_CHECK_FUNC macro reports that a function exists, but 169: when I try to use it, it always returns -1 and sets errno to ENOSYS. 170: 3.22. My program segfaults when I call fclose() on the FILE* returned 171: from setmntent(). Is this a glibc bug? 172: 3.23. I get "undefined reference to `atexit'" 173: 174: 4. Miscellaneous 175: 176: 4.1. After I changed configure.in I get `Autoconf version X.Y. 177: or higher is required for this script'. What can I do? 178: 4.2. When I try to compile code which uses IPv6 headers and 179: definitions on my Linux 2.x.y system I am in trouble. 180: Nothing seems to work. 181: 4.3. When I set the timezone by setting the TZ environment variable 182: to EST5EDT things go wrong since glibc computes the wrong time 183: from this information. 184: 4.4. What other sources of documentation about glibc are available? 185: 4.5. The timezone string for Sydney/Australia is wrong since even when 186: daylight saving time is in effect the timezone string is EST. 187: 4.6. I've build make 3.77 against glibc 2.1 and now make gets 188: segmentation faults. 189: 4.7. Why do so many programs using math functions fail on my AlphaStation? 190: 4.8. The conversion table for character set XX does not match with 191: what I expect. 192: 4.9. How can I find out which version of glibc I am using in the moment? 193: 4.10. Context switching with setcontext() does not work from within 194: signal handlers. 195: 196: ^L 197: ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 198: 199: 1. Compiling glibc 200: 201: 1.1. What systems does the GNU C Library run on? 202: 203: {UD} This is difficult to answer. The file `README' lists the architectures 204: GNU libc was known to run on *at some time*. This does not mean that it 205: still can be compiled and run on them now. 206: 207: The systems glibc is known to work on as of this release, and most probably 208: in the future, are: 209: 210: *-*-gnu GNU Hurd 211: i[3456]86-*-linux-gnu Linux-2.x on Intel 212: m68k-*-linux-gnu Linux-2.x on Motorola 680x0 213: alpha*-*-linux-gnu Linux-2.x on DEC Alpha 214: powerpc-*-linux-gnu Linux and MkLinux on PowerPC systems 215: powerpc64-*-linux-gnu Linux-2.4+ on 64-bit PowerPC systems 216: sparc-*-linux-gnu Linux-2.x on SPARC 217: sparc64-*-linux-gnu Linux-2.x on UltraSPARC 218: arm-*-none ARM standalone systems 219: arm-*-linux Linux-2.x on ARM 220: arm-*-linuxaout Linux-2.x on ARM using a.out binaries 221: mips*-*-linux-gnu Linux-2.x on MIPS 222: ia64-*-linux-gnu Linux-2.x on ia64 223: s390-*-linux-gnu Linux-2.x on IBM S/390 224: s390x-*-linux-gnu Linux-2.x on IBM S/390 64-bit 225: cris-*-linux-gnu Linux-2.4+ on CRIS 226: 227: Ports to other Linux platforms are in development, and may in fact work 228: already, but no one has sent us success reports for them. Currently no 229: ports to other operating systems are underway, although a few people have 230: expressed interest. 231: 232: If you have a system not listed above (or in the `README' file) and you are 233: really interested in porting it, see the GNU C Library web pages to learn 234: how to start contributing: 235: 236: http://www.gnu.org/software/libc/resources.html 237: 238: 239: 1.2. What compiler do I need to build GNU libc? 240: 241: {UD} You must use GNU CC to compile GNU libc. A lot of extensions of GNU CC 242: are used to increase portability and speed. 243: 244: GNU CC is found, like all other GNU packages, on 245: 246: ftp://ftp.gnu.org/pub/gnu 247: 248: and the many mirror sites. ftp.gnu.org is always overloaded, so try to find 249: a local mirror first. 250: 251: You should always try to use the latest official release. Older versions 252: may not have all the features GNU libc requires. The current releases of 253: gcc (3.2 or newer) should work with the GNU C library (for MIPS see question 1.20). 254: 255: Please note that gcc 2.95 and 2.95.x cannot compile glibc on Alpha due to 256: problems in the complex float support. 257: 258: 259: 1.3. When I try to compile glibc I get only error messages. 260: What's wrong? 261: 262: {UD} You definitely need GNU make to build GNU libc. No other make 263: program has the needed functionality. 264: 265: We recommend version GNU make version 3.79 or newer. Older versions have 266: bugs and/or are missing features. 267: 268: 269: 1.4. Do I need a special linker or assembler? 270: 271: {ZW} If you want a shared library, you need a linker and assembler that 272: understand all the features of ELF, including weak and versioned symbols. 273: The static library can be compiled with less featureful tools, but lacks key 274: features such as NSS. 275: 276: For Linux or Hurd, you want binutils 2.13 or higher. These are the only 277: versions we've tested and found reliable. Other versions may work but we 278: don't recommend them, especially not when C++ is involved. 279: 280: Other operating systems may come with system tools that have all the 281: necessary features, but this is moot because glibc hasn't been ported to 282: them. 283: 284: 285: 1.5. Which compiler should I use for powerpc? 286: 287: {} Removed. Does not apply anymore. 288: 289: 290: 1.6. Which tools should I use for ARM? 291: 292: {} Removed. Does not apply anymore. 293: 294: 295: 1.7. Do I need some more things to compile the GNU C Library? 296: 297: {UD} Yes, there are some more :-). 298: 299: * GNU gettext. This package contains the tools needed to construct 300: `message catalog' files containing translated versions of system 301: messages. See ftp://ftp.gnu.org/pub/gnu or better any mirror 302: site. (We distribute compiled message catalogs, but they may not be 303: updated in patches.) 304: 305: * Some files are built with special tools. E.g., files ending in .gperf 306: need a `gperf' program. The GNU version (now available in a separate 307: package, formerly only as part of libg++) is known to work while some 308: vendor versions do not. 309: 310: You should not need these tools unless you change the source files. 311: 312: * Perl 5 is needed if you wish to test an installation of GNU libc 313: as the primary C library. 314: 315: * When compiling for Linux, the header files of the Linux kernel must 316: be available to the compiler as <linux/*.h> and <asm/*.h>. 317: 318: * lots of disk space (~400MB for i?86-linux; more for RISC platforms). 319: 320: * plenty of time. Compiling just the shared and static libraries for 321: 35mins on a 2xPIII@550Mhz w/ 512MB RAM. On a 2xUltraSPARC-II@360Mhz 322: w/ 1GB RAM it takes about 14 minutes. Multiply this by 1.5 or 2.0 323: if you build profiling and/or the highly optimized version as well. 324: For Hurd systems times are much higher. 325: 326: You should avoid compiling in a NFS mounted filesystem. This is 327: very slow. 328: 329: James Troup <J.J.Troup@comp.brad.ac.uk> reports a compile time for 330: an earlier (and smaller!) version of glibc of 45h34m for a full build 331: (shared, static, and profiled) on Atari Falcon (Motorola 68030 @ 16 Mhz, 332: 14 Mb memory) and Jan Barte <yann@plato.uni-paderborn.de> reports 333: 22h48m on Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory) 334: 335: A full build of the PowerPC library took 1h on a PowerPC 750@400Mhz w/ 336: 64MB of RAM, and about 9h on a 601@60Mhz w/ 72Mb. 337: 338: 339: 1.8. What version of the Linux kernel headers should be used? 340: 341: {AJ,UD} The headers from the most recent Linux kernel should be used. The 342: headers used while compiling the GNU C library and the kernel binary used 343: when using the library do not need to match. The GNU C library runs without 344: problems on kernels that are older than the kernel headers used. The other 345: way round (compiling the GNU C library with old kernel headers and running 346: on a recent kernel) does not necessarily work. For example you can't use 347: new kernel features if you used old kernel headers to compile the GNU C 348: library. 349: 350: {ZW} Even if you are using a 2.0 kernel on your machine, we recommend you 351: compile GNU libc with 2.2 kernel headers. That way you won't have to 352: recompile libc if you ever upgrade to kernel 2.2. To tell libc which 353: headers to use, give configure the --with-headers switch 354: (e.g. --with-headers=/usr/src/linux-2.2.0/include). 355: 356: Note that you must configure the 2.2 kernel if you do this, otherwise libc 357: will be unable to find <linux/version.h>. Just change the current directory 358: to the root of the 2.2 tree and do `make include/linux/version.h'. 359: 360: 361: 1.9. The compiler hangs while building iconvdata modules. What's 362: wrong? 363: 364: {} Removed. Does not apply anymore. 365: 366: 367: 1.10. When I run `nm -u libc.so' on the produced library I still 368: find unresolved symbols. Can this be ok? 369: 370: {UD} Yes, this is ok. There can be several kinds of unresolved symbols: 371: 372: * magic symbols automatically generated by the linker. These have names 373: like __start_* and __stop_* 374: 375: * symbols starting with _dl_* come from the dynamic linker 376: 377: * weak symbols, which need not be resolved at all (fabs for example) 378: 379: Generally, you should make sure you find a real program which produces 380: errors while linking before deciding there is a problem. 381: 382: 383: 1.11. What are these `add-ons'? 384: 385: {UD} To avoid complications with export rules or external source code some 386: optional parts of the libc are distributed as separate packages, e.g., the 387: linuxthreads package. 388: 389: To use these packages as part of GNU libc, just unpack the tarfiles in the 390: libc source directory and tell the configuration script about them using the 391: --enable-add-ons option. If you give just --enable-add-ons configure tries 392: to find all the add-on packages in your source tree. This may not work. If 393: it doesn't, or if you want to select only a subset of the add-ons, give a 394: comma-separated list of the add-ons to enable: 395: 396: configure --enable-add-ons=linuxthreads 397: 398: for example. 399: 400: Add-ons can add features (including entirely new shared libraries), override 401: files, provide support for additional architectures, and just about anything 402: else. The existing makefiles do most of the work; only some few stub rules 403: must be written to get everything running. 404: 405: Most add-ons are tightly coupled to a specific GNU libc version. Please 406: check that the add-ons work with the GNU libc. For example the linuxthreads 407: add-on has the same numbering scheme as the libc and will in general only 408: work with the corresponding libc. 409: 410: {AJ} With glibc 2.2 the crypt add-on and with glibc 2.1 the localedata 411: add-on have been integrated into the normal glibc distribution, crypt and 412: localedata are therefore not anymore add-ons. 413: 414: 415: 1.12. My XXX kernel emulates a floating-point coprocessor for me. 416: Should I enable --with-fp? 417: 418: {ZW} An emulated FPU is just as good as a real one, as far as the C library 419: is concerned. You only need to say --without-fp if your machine has no way 420: to execute floating-point instructions. 421: 422: People who are interested in squeezing the last drop of performance 423: out of their machine may wish to avoid the trap overhead, but this is 424: far more trouble than it's worth: you then have to compile 425: *everything* this way, including the compiler's internal libraries 426: (libgcc.a for GNU C), because the calling conventions change. 427: 428: 429: 1.13. When compiling GNU libc I get lots of errors saying functions 430: in glibc are duplicated in libgcc. 431: 432: {EY} This is *exactly* the same problem that I was having. The problem was 433: due to the fact that configure didn't correctly detect that the linker flag 434: --no-whole-archive was supported in my linker. In my case it was because I 435: had run ./configure with bogus CFLAGS, and the test failed. 436: 437: One thing that is particularly annoying about this problem is that once this 438: is misdetected, running configure again won't fix it unless you first delete 439: config.cache. 440: 441: {UD} Starting with glibc-2.0.3 there should be a better test to avoid some 442: problems of this kind. The setting of CFLAGS is checked at the very 443: beginning and if it is not usable `configure' will bark. 444: 445: 446: 1.14. Why do I get messages about missing thread functions when I use 447: librt? I don't even use threads. 448: 449: {UD} In this case you probably mixed up your installation. librt uses 450: threads internally and has implicit references to the thread library. 451: Normally these references are satisfied automatically but if the thread 452: library is not in the expected place you must tell the linker where it is. 453: When using GNU ld it works like this: 454: 455: gcc -o foo foo.c -Wl,-rpath-link=/some/other/dir -lrt 456: 457: The `/some/other/dir' should contain the thread library. `ld' will use the 458: given path to find the implicitly referenced library while not disturbing 459: any other link path. 460: 461: 462: 1.15. What's the problem with configure --enable-omitfp? 463: 464: {AJ} When --enable-omitfp is set the libraries are built without frame 465: pointers. Some compilers produce buggy code for this model and therefore we 466: don't advise using it at the moment. 467: 468: If you use --enable-omitfp, you're on your own. If you encounter problems 469: with a library that was build this way, we advise you to rebuild the library 470: without --enable-omitfp. If the problem vanishes consider tracking the 471: problem down and report it as compiler failure. 472: 473: Since a library built with --enable-omitfp is undebuggable on most systems, 474: debuggable libraries are also built - you can use them by appending "_g" to 475: the library names. 476: 477: The compilation of these extra libraries and the compiler optimizations slow 478: down the build process and need more disk space. 479: 480: 481: 1.16. I get failures during `make check'. What should I do? 482: 483: {AJ} The testsuite should compile and run cleanly on your system; every 484: failure should be looked into. Depending on the failures, you probably 485: should not install the library at all. 486: 487: You should consider using the `glibcbug' script to report the failure, 488: providing as much detail as possible. If you run a test directly, please 489: remember to set up the environment correctly. You want to test the compiled 490: library - and not your installed one. The best way is to copy the exact 491: command line which failed and run the test from the subdirectory for this 492: test in the sources. 493: 494: There are some failures which are not directly related to the GNU libc: 495: - Some compilers produce buggy code. No compiler gets single precision 496: complex numbers correct on Alpha. Otherwise, gcc-3.2 should be ok. 497: - The kernel might have bugs. For example on Linux/Alpha 2.0.34 the 498: floating point handling has quite a number of bugs and therefore most of 499: the test cases in the math subdirectory will fail. Linux 2.2 has 500: fixes for the floating point support on Alpha. The Linux/SPARC kernel has 501: also some bugs in the FPU emulation code (as of Linux 2.2.0). 502: - Other tools might have problems. For example bash 2.03 gives a 503: segmentation fault running the tst-rpmatch.sh test script. 504: 505: 506: 1.17. What is symbol versioning good for? Do I need it? 507: 508: {AJ} Symbol versioning solves problems that are related to interface 509: changes. One version of an interface might have been introduced in a 510: previous version of the GNU C library but the interface or the semantics of 511: the function has been changed in the meantime. For binary compatibility 512: with the old library, a newer library needs to still have the old interface 513: for old programs. On the other hand, new programs should use the new 514: interface. Symbol versioning is the solution for this problem. The GNU 515: libc version 2.1 uses symbol versioning by default if the installed binutils 516: supports it. 517: 518: We don't advise building without symbol versioning, since you lose binary 519: compatibility - forever! The binary compatibility you lose is not only 520: against the previous version of the GNU libc (version 2.0) but also against 521: all future versions. 522: 523: 524: 1.18. How can I compile on my fast ix86 machine a working libc for my slow 525: i386? After installing libc, programs abort with "Illegal 526: Instruction". 527: 528: {AJ} glibc and gcc might generate some instructions on your machine that 529: aren't available on i386. You've got to tell glibc that you're configuring 530: for i386 with adding i386 as your machine, for example: 531: 532: ../configure --prefix=/usr i386-pc-linux-gnu 533: 534: And you need to tell gcc to only generate i386 code, just add `-mcpu=i386' 535: (just -m386 doesn't work) to your CFLAGS. 536: 537: {UD} This applies not only to the i386. Compiling on a i686 for any older 538: model will also fail if the above methods are not used. 539: 540: 541: 1.19. `make' complains about a missing dlfcn/libdl.so when building 542: malloc/libmemprof.so. How can I fix this? 543: 544: {AJ} Older make version (<= 3.78.90) have a bug which was hidden by a bug in 545: glibc (<= 2.1.2). You need to upgrade make to a newer or fixed version. 546: 547: After upgrading make, you should remove the file sysd-sorted in your build 548: directory. The problem is that the broken make creates a wrong order for 549: one list in that file. The list has to be recreated with the new make - 550: which happens if you remove the file. 551: 552: You might encounter this bug also in other situations where make scans 553: directories. I strongly advise to upgrade your make version to 3.79 or 554: newer. 555: 556: 557: 1.20. Which tools should I use for MIPS? 558: 559: {AJ} You should use the current development version of gcc 3.2 or newer from 560: CVS. 561: 562: You need also recent binutils, anything before and including 2.11 will not 563: work correctly. Either try the Linux binutils 2.11.90.0.5 from HJ Lu or the 564: current development version of binutils from CVS. 565: 566: Please note that `make check' might fail for a number of the math tests 567: because of problems of the FPU emulation in the Linux kernel (the MIPS FPU 568: doesn't handle all cases and needs help from the kernel). 569: 570: For details check also my page <http://www.suse.de/~aj/glibc-mips.html>. 571: 572: 573: 1.21. Which compiler should I use for powerpc64? 574: 575: {SM} You want to use at least gcc 3.2 (together with the right versions 576: of all the other tools, of course). 577: 578: 579: 1.22. `make' fails when running rpcgen the first time, 580: what is going on? How do I fix this? 581: 582: {CO} The first invocation of rpcgen is also the first use of the recently 583: compiled dynamic loader. If there is any problem with the dynamic loader 584: it will more than likely fail to run rpcgen properly. This could be due to 585: any number of problems. 586: 587: The only real solution is to debug the loader and determine the problem 588: yourself. Please remember that for each architecture there may be various 589: patches required to get glibc HEAD into a runnable state. The best course 590: of action is to determine if you have all the required patches. 591: 592: ^L 593: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594: 595: 2. Installation and configuration issues 596: 597: 2.1. Can I replace the libc on my Linux system with GNU libc? 598: 599: {UD} You cannot replace any existing libc for Linux with GNU libc. It is 600: binary incompatible and therefore has a different major version. You can, 601: however, install it alongside your existing libc. 602: 603: For Linux there are three major libc versions: 604: libc-4 a.out libc 605: libc-5 original ELF libc 606: libc-6 GNU libc 607: 608: You can have any combination of these three installed. For more information 609: consult documentation for shared library handling. The Makefiles of GNU 610: libc will automatically generate the needed symbolic links which the linker 611: will use. 612: 613: 614: 2.2. How do I configure GNU libc so that the essential libraries 615: like libc.so go into /lib and the other into /usr/lib? 616: 617: {UD,AJ} Like all other GNU packages GNU libc is designed to use a base 618: directory and install all files relative to this. The default is 619: /usr/local, because this is safe (it will not damage the system if installed 620: there). If you wish to install GNU libc as the primary C library on your 621: system, set the base directory to /usr (i.e. run configure --prefix=/usr 622: <other_options>). Note that this can damage your system; see question 2.3 for 623: details. 624: 625: Some systems like Linux have a filesystem standard which makes a difference 626: between essential libraries and others. Essential libraries are placed in 627: /lib because this directory is required to be located on the same disk 628: partition as /. The /usr subtree might be found on another 629: partition/disk. If you configure for Linux with --prefix=/usr, then this 630: will be done automatically. 631: 632: To install the essential libraries which come with GNU libc in /lib on 633: systems other than Linux one must explicitly request it. Autoconf has no 634: option for this so you have to use a `configparms' file (see the `INSTALL' 635: file for details). It should contain: 636: 637: slibdir=/lib 638: sysconfdir=/etc 639: 640: The first line specifies the directory for the essential libraries, the 641: second line the directory for system configuration files. 642: 643: 644: 2.3. How should I avoid damaging my system when I install GNU libc? 645: 646: {ZW} If you wish to be cautious, do not configure with --prefix=/usr. If 647: you don't specify a prefix, glibc will be installed in /usr/local, where it 648: will probably not break anything. (If you wish to be certain, set the 649: prefix to something like /usr/local/glibc2 which is not used for anything.) 650: 651: The dangers when installing glibc in /usr are twofold: 652: 653: * glibc will overwrite the headers in /usr/include. Other C libraries 654: install a different but overlapping set of headers there, so the effect 655: will probably be that you can't compile anything. You need to rename 656: /usr/include out of the way before running `make install'. (Do not throw 657: it away; you will then lose the ability to compile programs against your 658: old libc.) 659: 660: * None of your old libraries, static or shared, can be used with a 661: different C library major version. For shared libraries this is not a 662: problem, because the filenames are different and the dynamic linker 663: will enforce the restriction. But static libraries have no version 664: information. You have to evacuate all the static libraries in 665: /usr/lib to a safe location. 666: 667: The situation is rather similar to the move from a.out to ELF which 668: long-time Linux users will remember. 669: 670: 671: 2.4. Do I need to use GNU CC to compile programs that will use the 672: GNU C Library? 673: 674: {ZW} In theory, no; the linker does not care, and the headers are supposed 675: to check for GNU CC before using its extensions to the C language. 676: 677: However, there are currently no ports of glibc to systems where another 678: compiler is the default, so no one has tested the headers extensively 679: against another compiler. You may therefore encounter difficulties. If you 680: do, please report them as bugs. 681: 682: Also, in several places GNU extensions provide large benefits in code 683: quality. For example, the library has hand-optimized, inline assembly 684: versions of some string functions. These can only be used with GCC. See 685: question 3.8 for details. 686: 687: 688: 2.5. When linking with the new libc I get unresolved symbols 689: `crypt' and `setkey'. Why aren't these functions in the 690: libc anymore? 691: 692: {} Removed. Does not apply anymore. 693: 694: 695: 2.6. When I use GNU libc on my Linux system by linking against 696: the libc.so which comes with glibc all I get is a core dump. 697: 698: {UD} On Linux, gcc sets the dynamic linker to /lib/ld-linux.so.1 unless the 699: user specifies a --dynamic-linker argument. This is the name of the libc5 700: dynamic linker, which does not work with glibc. 701: 702: For casual use of GNU libc you can just specify to the linker 703: --dynamic-linker=/lib/ld-linux.so.2 704: 705: which is the glibc dynamic linker, on Linux systems. On other systems the 706: name is /lib/ld.so.1. When linking via gcc, you've got to add 707: -Wl,--dynamic-linker=/lib/ld-linux.so.2 708: 709: to the gcc command line. 710: 711: To change your environment to use GNU libc for compiling you need to change 712: the `specs' file of your gcc. This file is normally found at 713: 714: /usr/lib/gcc-lib/<arch>/<version>/specs 715: 716: In this file you have to change a few things: 717: 718: - change `ld-linux.so.1' to `ld-linux.so.2' 719: 720: - remove all expression `%{...:-lgmon}'; there is no libgmon in glibc 721: 722: - fix a minor bug by changing %{pipe:-} to %| 723: 724: Here is what the gcc-2.7.2 specs file should look like when GNU libc is 725: installed at /usr: 726: 727: ----------------------------------------------------------------------- 728: *asm: 729: %{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} 730: 731: *asm_final: 732: %| 733: 734: *cpp: 735: %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} 736: 737: *cc1: 738: %{profile:-p} 739: 740: *cc1plus: 741: 742: 743: *endfile: 744: %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s 745: 746: *link: 747: -m elf_i386 %{shared:-shared} %{!shared: %{!ibcs: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}} %{static:-static}}} 748: 749: *lib: 750: %{!shared: %{pthread:-lpthread} %{profile:-lc_p} %{!profile: -lc}} 751: 752: *libgcc: 753: -lgcc 754: 755: *startfile: 756: %{!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} 757: 758: *switches_need_spaces: 759: 760: 761: *signed_char: 762: %{funsigned-char:-D__CHAR_UNSIGNED__} 763: 764: *predefines: 765: -D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) 766: 767: *cross_compile: 768: 0 769: 770: *multilib: 771: . ; 772: 773: ----------------------------------------------------------------------- 774: 775: Things get a bit more complicated if you have GNU libc installed in some 776: other place than /usr, i.e., if you do not want to use it instead of the old 777: libc. In this case the needed startup files and libraries are not found in 778: the regular places. So the specs file must tell the compiler and linker 779: exactly what to use. 780: 781: Version 2.7.2.3 does and future versions of GCC will automatically 782: provide the correct specs. 783: 784: 785: 2.7. Looking through the shared libc file I haven't found the 786: functions `stat', `lstat', `fstat', and `mknod' and while 787: linking on my Linux system I get error messages. How is 788: this supposed to work? 789: 790: {RM} Believe it or not, stat and lstat (and fstat, and mknod) are supposed 791: to be undefined references in libc.so.6! Your problem is probably a missing 792: or incorrect /usr/lib/libc.so file; note that this is a small text file now, 793: not a symlink to libc.so.6. It should look something like this: 794: 795: GROUP ( libc.so.6 libc_nonshared.a ) 796: 797: 798: 2.8. When I run an executable on one system which I compiled on 799: another, I get dynamic linker errors. Both systems have the same 800: version of glibc installed. What's wrong? 801: 802: {ZW} Glibc on one of these systems was compiled with gcc 2.7 or 2.8, the 803: other with egcs (any version). Egcs has functions in its internal 804: `libgcc.a' to support exception handling with C++. They are linked into 805: any program or dynamic library compiled wit