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