FAQ.in

   1             Frequently Asked Questions about the GNU C Library
   2
   3 This document tries to answer questions a user might have when
   4 installing and using glibc.  Please make sure you read this before
   5 sending questions or bug reports to the maintainers.
   6
   7 The GNU C library is very complex.  The installation process has not
   8 been completely automated; there are too many variables. You can do
   9 substantial damage to your system by installing the library
  10 incorrectly.  Make sure you understand what you are undertaking before
  11 you begin.
  12
  13 If you have any questions you think should be answered in this document,
  14 please let me know.
  15
  16                                                   --drepper@cygnus.com
  17 \f
  18 ? Compiling glibc
  19
  20 ??      What systems does the GNU C Library run on?
  21
  22 {UD} This is difficult to answer.  The file `README' lists the
  23 architectures GNU libc was known to run on *at some time*.  This does
  24 not mean that it still can be compiled and run on them now.
  25
  26 The systems glibc is known to work on as of this release, and most
  27 probably in the future, are:
  28
  29         *-*-gnu                 GNU Hurd
  30         i[3456]86-*-linux-gnu   Linux-2.x on Intel
  31         m68k-*-linux-gnu        Linux-2.x on Motorola 680x0
  32         alpha-*-linux-gnu       Linux-2.x on DEC Alpha
  33         powerpc-*-linux-gnu     Linux and MkLinux on PowerPC systems
  34         sparc-*-linux-gnu       Linux-2.x on SPARC
  35         sparc64-*-linux-gnu     Linux-2.x on UltraSPARC
  36
  37 Ports to other Linux platforms are in development, and may in fact
  38 work already, but no one has sent us success reports for them.
  39 Currently no ports to other operating systems are underway, although a
  40 few people have expressed interest.
  41
  42 If you have a system not listed above (or in the `README' file) and
  43 you are really interested in porting it, contact
  44
  45         <bug-glibc@gnu.org>
  46
  47 ??      What compiler do I need to build GNU libc?
  48
  49 {UD} You must use GNU CC to compile GNU libc.  A lot of extensions of
  50 GNU CC are used to increase portability and speed.
  51
  52 GNU CC is found, like all other GNU packages, on
  53         ftp://prep.ai.mit.edu/pub/gnu
  54 and the many mirror sites.  prep is always overloaded, so try to find
  55 a local mirror first.
  56
  57 You always should try to use the latest official release.  Older
  58 versions may not have all the features GNU libc requires.  On most
  59 supported platforms, 2.7.2.3 is the earliest version that works at all.
  60
  61 ??      When I try to compile glibc I get only error messages.
  62         What's wrong?
  63
  64 {UD} You definitely need GNU make to translate GNU libc.  No
  65 other make program has the needed functionality.
  66
  67 We recommend version GNU make version 3.75.  Versions 3.76 and 3.76.1
  68 have bugs which appear when building big projects like GNU libc.
  69 Versions before 3.74 have bugs and/or are missing features.
  70
  71 ??      Do I need a special linker or archiver?
  72
  73 {UD} You may be able to use your system linker, but GNU libc works
  74 best with GNU binutils.
  75
  76 On systems where the native linker does not support weak symbols you
  77 will not get a fully ISO C compliant C library.  Generally speaking
  78 you should use the GNU binutils if they provide at least the same
  79 functionality as your system's tools.
  80
  81 Always get the newest release of GNU binutils available.  Older
  82 releases are known to have bugs that prevent a successful compilation.
  83
  84 {ZW} As of release 2.1 a linker supporting symbol versions is
  85 required.  For Linux, get binutils-2.8.1.0.17 or later.  Other systems
  86 may have native linker support, but it's moot right now, because glibc
  87 has not been ported to them.
  88
  89 ??      Do I need some more things to compile GNU C Library?
  90
  91 {UD} Yes, there are some more :-).
  92
  93 * GNU gettext.  This package contains the tools needed to construct
  94   `message catalog' files containing translated versions of system
  95   messages. See ftp://prep.ai.mit.edu/pub/gnu or better any mirror
  96   site.  (We distribute compiled message catalogs, but they may not be
  97   updated in patches.)
  98
  99 * Some files depend on special tools.  E.g., files ending in .gperf
 100   need a `gperf' program.  The GNU version (part of libg++) is known
 101   to work while some vendor versions do not.
 102
 103   You should not need these tools unless you change the source files.
 104
 105 * Some scripts need perl5 - but at the moment those scripts are not
 106   vital for building and installing GNU libc (some data files will not
 107   be created).
 108
 109 * When compiling for Linux, the header files of the Linux kernel must
 110   be available to the compiler as <linux/*.h> and <asm/*.h>.
 111
 112 * lots of disk space (~170MB for i?86-linux; more for RISC platforms).
 113
 114 * plenty of time.  Compiling just the shared and static libraries for
 115   i?86-linux takes approximately 1h on an i586@133, or 2.5h on
 116   i486@66, or 4.5h on i486@33.  Multiply this by 1.5 or 2.0 if you
 117   build profiling and/or the highly optimized version as well.  For
 118   Hurd systems times are much higher.
 119
 120   You should avoid compiling in a NFS mounted filesystem.  This is
 121   very slow.
 122
 123   James Troup <J.J.Troup@comp.brad.ac.uk> reports a compile time of
 124   45h34m for a full build (shared, static, and profiled) on Atari
 125   Falcon (Motorola 68030 @ 16 Mhz, 14 Mb memory) and Jan Barte
 126   <yann@plato.uni-paderborn.de> reports 22h48m on Atari TT030
 127   (Motorola 68030 @ 32 Mhz, 34 Mb memory)
 128
 129   If you have some more measurements let me know.
 130
 131 ??      When I run `nm -u libc.so' on the produced library I still
 132         find unresolved symbols.  Can this be ok?
 133
 134 {UD} Yes, this is ok.  There can be several kinds of unresolved
 135 symbols:
 136
 137 * magic symbols automatically generated by the linker.  These have names
 138   like __start_* and __stop_*
 139
 140 * symbols starting with _dl_* come from the dynamic linker
 141
 142 * symbols resolved by using libgcc.a
 143   (__udivdi3, __umoddi3, or similar)
 144
 145 * weak symbols, which need not be resolved at all (fabs for example)
 146
 147 Generally, you should make sure you find a real program which produces
 148 errors while linking before deciding there is a problem.
 149
 150 ??addon What are these `add-ons'?
 151
 152 {UD} To avoid complications with export rules or external source
 153 code some optional parts of the libc are distributed as separate
 154 packages (e.g., the crypt package, see ?crypt).
 155
 156 To use these packages as part of GNU libc, just unpack the tarfiles in
 157 the libc source directory and tell the configuration script about them
 158 using the --enable-add-ons option.  If you give just --enable-add-ons
 159 configure tries to find all the add-on packages in your source tree.
 160 This may not work.  If it doesn't, or if you want to select only a
 161 subset of the add-ons, give a comma-separated list of the add-ons to
 162 enable:
 163
 164         configure --enable-add-ons=crypt,linuxthreads
 165
 166 for example.
 167
 168 Add-ons can add features (including entirely new shared libraries),
 169 override files, provide support for additional architectures, and
 170 just about anything else.  The existing makefiles do most of the work;
 171 only some few stub rules must be written to get everything running.
 172
 173 ??      My XXX kernel emulates a floating-point coprocessor for me.
 174         Should I enable --with-fp?
 175
 176 {ZW} An emulated FPU is just as good as a real one, as far as the C
 177 library is concerned.  You only need to say --without-fp if your
 178 machine has no way to execute floating-point instructions.
 179
 180 People who are interested in squeezing the last drop of performance
 181 out of their machine may wish to avoid the trap overhead, but this is
 182 far more trouble than it's worth: you then have to compile
 183 *everything* this way, including the compiler's internal libraries
 184 (libgcc.a for GNU C), because the calling conventions change.
 185
 186 ??      When compiling GNU libc I get lots of errors saying functions
 187         in glibc are duplicated in libgcc.
 188
 189 {EY} This is *exactly* the same problem that I was having.  The
 190 problem was due to the fact that configure didn't correctly detect
 191 that the linker flag --no-whole-archive was supported in my linker.
 192 In my case it was because I had run ./configure with bogus CFLAGS, and
 193 the test failed.
 194
 195 One thing that is particularly annoying about this problem is that
 196 once this is misdetected, running configure again won't fix it unless
 197 you first delete config.cache.
 198
 199 {UD} Starting with glibc-2.0.3 there should be a better test to avoid
 200 some problems of this kind.  The setting of CFLAGS is checked at the
 201 very beginning and if it is not usable `configure' will bark.
 202
 203 ??      Why do I get messages about missing thread functions when I use
 204         the librt?  I don't even use threads.
 205
 206 {UD} In this case you probably mixed up your installation of the libc.
 207 The librt internally uses threads and it has implicit references to
 208 the thread library.  Normally these references are satisfied
 209 automatically but if the thread library belonging to the librt is not
 210 in the expected place one has to specify this place.  When using GNU
 211 ld it works like this:
 212
 213         gcc -o foo foo.c -Wl,-rpath-link=/some/other/dir -lrt
 214
 215 The `/some/other/dir' should contain the matching thread library and
 216 `ld' will use the given path to find the implicitly referenced library
 217 while not disturbing any other link path order.
 218
 219 ??      What's the problem with configure --enable-omitfp?
 220
 221 {AJ} When --enable-omitfp is set the libraries are built without frame
 222 pointers. Some compilers produce buggy code for this model and
 223 therefore we don't advise using it at the moment.
 224
 225 If you use --enable-omitfp, you're on your own. If you encounter
 226 problems with a library that was build this way, we advise you to
 227 rebuild the library without --enable-omitfp.  If the problem vanishes
 228 consider tracking the problem down and report it as compiler failure.
 229
 230 Since a library build with --enable-omitfp is undebuggable on most
 231 systems, debuggable libraries are also built - you can use it by
 232 appending "_g" to the library names.
 233
 234 The compilation of these extra libraries and the compiler optimizations
 235 slow down the build process and need more disk space.
 236
 237 ? Installation and configuration issues
 238
 239 ??      Can I replace the libc on my Linux system with GNU libc?
 240
 241 {UD} You cannot replace any existing libc for Linux with GNU
 242 libc.  It is binary incompatible and therefore has a different major
 243 version.  You can, however, install it alongside your existing libc.
 244
 245 For Linux there are three major libc versions:
 246         libc-4          a.out libc
 247         libc-5          original ELF libc
 248         libc-6          GNU libc
 249
 250 You can have any combination of these three installed.  For more
 251 information consult documentation for shared library handling.  The
 252 Makefiles of GNU libc will automatically generate the needed symbolic
 253 links which the linker will use.
 254
 255 ??      How do I configure GNU libc so that the essential libraries
 256         like libc.so go into /lib and the other into /usr/lib?
 257
 258 {UD,AJ} Like all other GNU packages GNU libc is designed to use a base
 259 directory and install all files relative to this.  The default is
 260 /usr/local, because this is safe (it will not damage the system if
 261 installed there).  If you wish to install GNU libc as the primary C
 262 library on your system, set the base directory to /usr (i.e. run
 263 configure --prefix=/usr <other_options>).  Note that this can damage
 264 your system; see ?safety for details.
 265
 266 Some systems like Linux have a filesystem standard which makes a
 267 difference between essential libraries and others.  Essential
 268 libraries are placed in /lib because this directory is required to be
 269 located on the same disk partition as /.  The /usr subtree might be
 270 found on another partition/disk. If you configure for Linux with
 271 --prefix=/usr, then this will be done automatically.
 272
 273 To install the essential libraries which come with GNU libc in /lib on
 274 systems other than Linux one must explicitly request it.  Autoconf has
 275 no option for this so you have to use a `configparms' file (see the
 276 `INSTALL' file for details).  It should contain:
 277
 278 slibdir=/lib
 279 sysconfdir=/etc
 280
 281 The first line specifies the directory for the essential libraries,
 282 the second line the directory for system configuration files.
 283
 284 ??safety        How should I avoid damaging my system when I install GNU libc?
 285
 286 {ZW} If you wish to be cautious, do not configure with --prefix=/usr.
 287 If you don't specify a prefix, glibc will be installed in /usr/local,
 288 where it will probably not break anything.  (If you wish to be
 289 certain, set the prefix to something like /usr/local/glibc2 which is
 290 not used for anything.)
 291
 292 The dangers when installing glibc in /usr are twofold:
 293
 294 * glibc will overwrite the headers in /usr/include.  Other C libraries
 295   install a different but overlapping set of headers there, so the
 296   effect will probably be that you can't compile anything.  You need to
 297   rename /usr/include out of the way first.  (Do not throw it away; you
 298   will then lose the ability to compile programs against your old libc.)
 299
 300 * None of your old libraries, static or shared, can be used with a
 301   different C library major version.  For shared libraries this is not a
 302   problem, because the filenames are different and the dynamic linker
 303   will enforce the restriction.  But static libraries have no version
 304   information.  You have to evacuate all the static libraries in
 305   /usr/lib to a safe location.
 306
 307 The situation is rather similar to the move from a.out to ELF which
 308 long-time Linux users will remember.
 309
 310 ??      Do I need to use GNU CC to compile programs that will use the
 311         GNU C Library?
 312
 313 {ZW} In theory, no; the linker does not care, and the headers are
 314 supposed to check for GNU CC before using its extensions to the C
 315 language.
 316
 317 However, there are currently no ports of glibc to systems where
 318 another compiler is the default, so no one has tested the headers
 319 extensively against another compiler.  You may therefore encounter
 320 difficulties.  If you do, please report them as bugs.
 321
 322 Also, in several places GNU extensions provide large benefits in code
 323 quality.  For example, the library has hand-optimized, inline assembly
 324 versions of some string functions.  These can only be used with GCC.
 325 See ?string for details.
 326
 327 ??crypt When linking with the new libc I get unresolved symbols
 328         `crypt' and `setkey'.  Why aren't these functions in the
 329         libc anymore?
 330
 331 {UD} The US places restrictions on exporting cryptographic programs
 332 and source code.  Until this law gets abolished we cannot ship the
 333 cryptographic functions together with glibc.
 334
 335 The functions are available, as an add-on (see ?addon).  People in the
 336 US may get it from the same place they got GNU libc from.  People
 337 outside the US should get the code from ftp://ftp.ifi.uio.no/pub/gnu,
 338 or another archive site outside the USA.  The README explains how to
 339 install the sources.
 340
 341 If you already have the crypt code on your system the reason for the
 342 failure is probably that you did not link with -lcrypt.  The crypto
 343 functions are in a separate library to make it possible to export GNU
 344 libc binaries from the US.
 345
 346 ??      When I use GNU libc on my Linux system by linking against
 347         the libc.so which comes with glibc all I get is a core dump.
 348
 349 {UD} On Linux, gcc sets the dynamic linker to /lib/ld-linux.so.1
 350 unless the user specifies a -dynamic-linker argument.  This is the
 351 name of the libc5 dynamic linker, which does not work with glibc.
 352
 353 For casual use of GNU libc you can just specify
 354     -dynamic-linker=/lib/ld-linux.so.2
 355
 356 which is the glibc dynamic linker, on Linux systems.  On other systems
 357 the name is /lib/ld.so.1.
 358
 359 To change your environment to use GNU libc for compiling you need to
 360 change the `specs' file of your gcc.  This file is normally found at
 361
 362         /usr/lib/gcc-lib/<arch>/<version>/specs
 363
 364 In this file you have to change a few things:
 365
 366 - change `ld-linux.so.1' to `ld-linux.so.2'
 367
 368 - remove all expression `%{...:-lgmon}';  there is no libgmon in glibc
 369
 370 - fix a minor bug by changing %{pipe:-} to %|
 371
 372 Here is what the gcc-2.7.2 specs file should look like when GNU libc
 373 is installed at /usr:
 374
 375 -----------------------------------------------------------------------
 376 *asm:
 377 %{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
 378
 379 *asm_final:
 380 %|
 381
 382 *cpp:
 383 %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
 384
 385 *cc1:
 386 %{profile:-p}
 387
 388 *cc1plus:
 389
 390
 391 *endfile:
 392 %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s
 393
 394 *link:
 395 -m elf_i386 %{shared:-shared}   %{!shared:     %{!ibcs:       %{!static:        %{rdynamic:-export-dynamic}     %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}}  %{static:-static}}}
 396
 397 *lib:
 398 %{!shared: %{pthread:-lpthread}         %{profile:-lc_p} %{!profile: -lc}}
 399
 400 *libgcc:
 401 -lgcc
 402
 403 *startfile:
 404 %{!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}
 405
 406 *switches_need_spaces:
 407
 408
 409 *signed_char:
 410 %{funsigned-char:-D__CHAR_UNSIGNED__}
 411
 412 *predefines:
 413 -D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386)
 414
 415 *cross_compile:
 416 0
 417
 418 *multilib:
 419 . ;
 420
 421 -----------------------------------------------------------------------
 422
 423 Things get a bit more complicated if you have GNU libc installed in
 424 some other place than /usr, i.e., if you do not want to use it instead
 425 of the old libc.  In this case the needed startup files and libraries
 426 are not found in the regular places.  So the specs file must tell the
 427 compiler and linker exactly what to use.
 428
 429 Version 2.7.2.3 does and future versions of GCC will automatically
 430 provide the correct specs.
 431
 432 ??      Looking through the shared libc file I haven't found the
 433         functions `stat', `lstat', `fstat', and `mknod' and while
 434         linking on my Linux system I get error messages.  How is
 435         this supposed to work?
 436
 437 {RM} Believe it or not, stat and lstat (and fstat, and mknod)
 438 are supposed to be undefined references in libc.so.6!  Your problem is
 439 probably a missing or incorrect /usr/lib/libc.so file; note that this
 440 is a small text file now, not a symlink to libc.so.6.  It should look
 441 something like this:
 442
 443 GROUP ( libc.so.6 ld.so.1 libc.a )
 444
 445 or in ix86/Linux and alpha/Linux:
 446
 447 GROUP ( libc.so.6 ld-linux.so.2 libc.a )
 448
 449 ??      How can I compile gcc 2.7.2.1 from the gcc source code using
 450         glibc 2.x?
 451
 452 {AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3
 453 or later.  You should get at least gcc 2.7.2.3.  All previous versions
 454 had problems with glibc support.
 455
 456 ??      The `gencat' utility cannot process the catalog sources which
 457         were used on my Linux libc5 based system.  Why?
 458
 459 {UD} The `gencat' utility provided with glibc complies to the XPG
 460 standard.  The older Linux version did not obey the standard, so they
 461 are not compatible.
 462
 463 To ease the transition from the Linux version some of the non-standard
 464 features are also present in the `gencat' program of GNU libc.  This
 465 mainly includes the use of symbols for the message number and the automatic
 466 generation of header files which contain the needed #defines to map the
 467 symbols to integers.
 468
 469 Here is a simple SED script to convert at least some Linux specific
 470 catalog files to the XPG4 form:
 471
 472 -----------------------------------------------------------------------
 473 # Change catalog source in Linux specific format to standard XPG format.
 474 # Ulrich Drepper <drepper@cygnus.com>, 1996.
 475 #
 476 /^\$ #/ {
 477   h
 478   s/\$ #\([^ ]*\).*/\1/
 479   x
 480   s/\$ #[^ ]* *\(.*\)/\$ \1/
 481 }
 482
 483 /^# / {
 484   s/^# \(.*\)/\1/
 485   G
 486   s/\(.*\)\n\(.*\)/\2 \1/
 487 }
 488 -----------------------------------------------------------------------
 489
 490 ??      I have set up /etc/nis.conf, and the Linux libc 5 with NYS
 491         works great.  But the glibc NIS+ doesn't seem to work.
 492
 493 {TK} The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START
 494 file for storing information about the NIS+ server and their public
 495 keys, because the nis.conf file does not contain all the necessary
 496 information.  You have to copy a NIS_COLD_START file from a Solaris
 497 client (the NIS_COLD_START file is byte order independent) or generate
 498 it with nisinit from the nis-tools package (available at
 499 http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html).
 500
 501 ??      After installing glibc name resolving doesn't work properly.
 502
 503 {AJ} You probably should read the manual section describing
 504 nsswitch.conf (just type `info libc "NSS Configuration File"').
 505 The NSS configuration file is usually the culprit.
 506
 507 ??      I have /usr/include/net and /usr/include/scsi as symlinks
 508         into my Linux source tree.  Is that wrong?
 509
 510 {PB} This was necessary for libc5, but is not correct when using
 511 glibc.  Including the kernel header files directly in user programs
 512 usually does not work (see ?kerhdr).  glibc provides its own <net/*>
 513 and <scsi/*> header files to replace them, and you may have to remove
 514 any symlink that you have in place before you install glibc.  However,
 515 /usr/include/asm and /usr/include/linux should remain as they were.
 516
 517 ??      Programs like `logname', `top', `uptime' `users', `w' and
 518         `who', show incorrect information about the (number of)
 519         users on my system.  Why?
 520
 521 {MK} See ?getlog.
 522
 523 ??      After upgrading to glibc 2.1 with symbol versioning I get
 524         errors about undefined symbols.  What went wrong?
 525
 526 {AJ} The problem is caused either by wrong program code or tools.  In
 527 the versioned libc a lot of symbols are now local that were global
 528 symbols in previous versions.  It seems that programs linked against
 529 older versions often accidentally used libc global variables --
 530 something that should not happen.
 531
 532 The only way to fix this is to recompile your program. Sorry, that's
 533 the price you might have to pay once for quite a number of advantages
 534 with symbol versioning.
 535
 536 ??      When I start the program XXX after upgrading the library
 537         I get
 538           XXX: Symbol `_sys_errlist' has different size in shared
 539           object, consider re-linking
 540         Why?  What should I do?
 541
 542 {UD} As the message says, relink the binary.  The problem is that
 543 a few symbols from the library can change in size and there is no way
 544 to avoid this.  _sys_errlist is a good example.  Occasionally there are
 545 new error numbers added to the kernel and this must be reflected at user
 546 level, breaking programs that refer to them directly.
 547
 548 Such symbols should normally not be used at all.  There are mechanisms
 549 to avoid using them.  In the case of _sys_errlist, there is the
 550 strerror() function which should _always_ be used instead.  So the
 551 correct fix is to rewrite that part of the application.
 552
 553 In some situations (especially when testing a new library release) it
 554 might be possible that a symbol changed size when that should not have
 555 happened.  So in case of doubt report such a warning message as a
 556 problem.
 557
 558 ? Source and binary incompatibilities, and what to do about them
 559
 560 ??      I expect GNU libc to be 100% source code compatible with
 561         the old Linux based GNU libc.  Why isn't it like this?
 562
 563 {DMT,UD} Not every extension in Linux libc's history was well
 564 thought-out.  In fact it had a lot of problems with standards compliance
 565 and with cleanliness.  With the introduction of a new version number these
 566 errors can now be corrected.  Here is a list of the known source code
 567 incompatibilities:
 568
 569 * _GNU_SOURCE: glibc does not make the GNU extensions available
 570   automatically.  If a program depends on GNU extensions or some
 571   other non-standard functionality, it is necessary to compile it
 572   with the C compiler option -D_GNU_SOURCE, or better, to put
 573   `#define _GNU_SOURCE' at the beginning of your source files, before
 574   any C library header files are included.  This difference normally
 575   manifests itself in the form of missing prototypes and/or data type
 576   definitions.  Thus, if you get such errors, the first thing you
 577   should do is try defining _GNU_SOURCE and see if that makes the
 578   problem go away.
 579
 580   For more information consult the file `NOTES' in the GNU C library
 581   sources.
 582
 583 * reboot(): GNU libc sanitizes the interface of reboot() to be more
 584   compatible with the interface used on other OSes.  reboot() as
 585   implemented in glibc takes just one argument.  This argument
 586   corresponds to the third argument of the Linux reboot system call.
 587   That is, a call of the form reboot(a, b, c) needs to be changed into
 588   reboot(c).  Beside this the header <sys/reboot.h> defines the needed
 589   constants for the argument.  These RB_* constants should be used
 590   instead of the cryptic magic numbers.
 591
 592 * swapon(): the interface of this function didn't change, but the
 593   prototype is in a separate header file <sys/swap.h>.  This header
 594   file also provides the SWAP_* constants defined by <linux/swap.h>;
 595   you should use them for the second argument to swapon().
 596
 597 * errno: If a program uses the variable "errno", then it _must_
 598   include <errno.h>.  The old libc often (erroneously) declared this
 599   variable implicitly as a side-effect of including other libc header
 600   files.  glibc is careful to avoid such namespace pollution, which,
 601   in turn, means that you really need to include the header files that
 602   you depend on.  This difference normally manifests itself in the
 603   form of the compiler complaining about references to an undeclared
 604   symbol "errno".
 605
 606 * Linux-specific syscalls: All Linux system calls now have appropriate
 607   library wrappers and corresponding declarations in various header files.
 608   This is because the syscall() macro that was traditionally used to
 609   work around missing syscall wrappers are inherently non-portable and
 610   error-prone.  The following table lists all the new syscall stubs,
 611   the header-file declaring their interface and the system call name.
 612
 613        syscall name:    wrapper name:   declaring header file:
 614        -------------    -------------   ----------------------
 615        bdflush          bdflush         <sys/kdaemon.h>
 616        syslog           ksyslog_ctl     <sys/klog.h>
 617
 618 * lpd: Older versions of lpd depend on a routine called _validuser().
 619   The library does not provide this function, but instead provides
 620   __ivaliduser() which has a slightly different interface.  Simply
 621   upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD
 622   lpd is known to be working).
 623
 624 * resolver functions/BIND: like on many other systems the functions of
 625   the resolver library are not included in libc itself.  There is a
 626   separate library libresolv.  If you get undefined symbol errors for
 627   symbols starting with `res_*' simply add -lresolv to your linker
 628   command line.
 629
 630 * the `signal' function's behavior corresponds to the BSD semantic and
 631   not the SysV semantic as it was in libc-5.  The interface on all GNU
 632   systems shall be the same and BSD is the semantic of choice.  To use
 633   the SysV behavior simply use `sysv_signal', or define _XOPEN_SOURCE.
 634   See ?signal for details.
 635
 636 ??getlog        Why does getlogin() always return NULL on my Linux box?
 637
 638 {UD} The GNU C library has a format for the UTMP and WTMP file which
 639 differs from what your system currently has.  It was extended to
 640 fulfill the needs of the next years when IPv6 is introduced.  The
 641 record size is different and some fields have different positions.
 642 The files written by functions from the one library cannot be read by
 643 functions from the other library.  Sorry, but this is what a major
 644 release is for.  It's better to have a cut now than having no means to
 645 support the new techniques later.
 646
 647 {MK} There is however a (partial) solution for this problem.  Please
 648 take a look at the file `login/README.utmpd'.
 649
 650 ??      Where are the DST_* constants found in <sys/time.h> on many
 651         systems?
 652
 653 {UD} These constants come from the old BSD days and are not used
 654 anymore (libc5 does not actually implement the handling although the
 655 constants are defined).
 656
 657 Instead GNU libc contains zone database support and compatibility code
 658 for POSIX TZ environment variable handling.
 659
 660 ??      The prototypes for `connect', `accept', `getsockopt',
 661         `setsockopt', `getsockname', `getpeername', `send',
 662         `sendto', and `recvfrom' are different in GNU libc from
 663         any other system I saw.  This is a bug, isn't it?
 664
 665 {UD} No, this is no bug.  This version of GNU libc already follows the
 666 new Single Unix specifications (and I think the POSIX.1g draft which
 667 adopted the solution).  The type for a parameter describing a size is
 668 now `socklen_t', a new type.
 669
 670 ??kerhdr        On Linux I've got problems with the declarations in Linux
 671         kernel headers.
 672
 673 {UD,AJ} On Linux, the use of kernel headers is reduced to the minimum.
 674 This gives Linus the ability to change the headers more freely.  Also,
 675 user programs are now insulated from changes in the size of kernel
 676 data structures.
 677
 678 For example, the sigset_t type is 32 or 64 bits wide in the kernel.
 679 In glibc it is 1024 bits wide.  This guarantees that when the kernel
 680 gets a bigger sigset_t (for POSIX.1e realtime support, say) user
 681 programs will not have to be recompiled.  Consult the header files for
 682 more information about the changes.
 683
 684 Therefore you shouldn't include Linux kernel header files directly if
 685 glibc has defined a replacement. Otherwise you might get undefined
 686 results because of type conflicts.
 687
 688 ??      I don't include any kernel headers myself but the compiler
 689         still complains about redeclarations of types in the kernel
 690         headers.
 691
 692 {UD} The kernel headers before Linux 2.1.61 and 2.0.32 don't work
 693 correctly with glibc.  Compiling C programs is possible in most cases
 694 but C++ programs have (due to the change of the name lookups for
 695 `struct's) problems.  One prominent example is `struct fd_set'.
 696
 697 There might be some problems left but 2.1.61/2.0.32 fix most of the
 698 known ones.  See the BUGS file for other known problems.
 699
 700 ??signal        Why don't signals interrupt system calls anymore?
 701
 702 {ZW} By default GNU libc uses the BSD semantics for signal(),
 703 unlike Linux libc 5 which used System V semantics.  This is partially
 704 for compatibility with other systems and partially because the BSD
 705 semantics tend to make programming with signals easier.
 706
 707 There are three differences:
 708
 709 * BSD-style signals that occur in the middle of a system call do not
 710   affect the system call; System V signals cause the system call to
 711   fail and set errno to EINTR.
 712
 713 * BSD signal handlers remain installed once triggered.  System V signal
 714   handlers work only once, so one must reinstall them each time.
 715
 716 * A BSD signal is blocked during the execution of its handler.  In other
 717   words, a handler for SIGCHLD (for example) does not need to worry about
 718   being interrupted by another SIGCHLD.  It may, however, be interrupted
 719   by other signals.
 720
 721 There is general consensus that for `casual' programming with signals, the
 722 BSD semantics are preferable.  You don't need to worry about system calls
 723 returning EINTR, and you don't need to worry about the race conditions
 724 associated with one-shot signal handlers.
 725
 726 If you are porting an old program that relies on the old semantics, you can
 727 quickly fix the problem by changing signal() to sysv_signal() throughout.
 728 Alternatively, define _XOPEN_SOURCE before including <signal.h>.
 729
 730 For new programs, the sigaction() function allows you to specify precisely
 731 how you want your signals to behave.  All three differences listed above are
 732 individually switchable on a per-signal basis with this function.
 733
 734 If all you want is for one specific signal to cause system calls to fail
 735 and return EINTR (for example, to implement a timeout) you can do this with
 736 siginterrupt().
 737
 738
 739 ??string        I've got errors compiling code that uses certain string
 740         functions.  Why?
 741
 742 {AJ} glibc 2.1 has special string functions that are faster
 743 than the normal library functions. Some of the functions are
 744 implemented as inline functions and others as macros.
 745
 746 The optimized string functions are only used when compiling with
 747 optimizations (-O1 or higher). The behavior can be changed with two
 748 feature macros:
 749
 750 * __NO_STRING_INLINES: Don't do any string optimizations.
 751 * __USE_STRING_INLINES: Use assembly language inline functions (might
 752   increase code size dramatically).
 753
 754 Since some of these string functions are now additionally defined as
 755 macros, code like "char *strncpy();" doesn't work anymore (and is
 756 unnecessary, since <string.h> has the necessary declarations). Either
 757 change your code or define __NO_STRING_INLINES.
 758
 759 {UD} Another problem in this area is that gcc still has problems on
 760 machines with very few registers (e.g., ix86).  The inline assembler
 761 code can require almost all the registers and the register allocator
 762 cannot always handle this situation.
 763
 764 One can disable the string optimizations selectively.  Instead of writing
 765
 766         cp = strcpy (foo, "lkj");
 767
 768 one can write
 769
 770         cp = (strcpy) (foo, "lkj");
 771
 772 This disables the optimization for that specific call.
 773
 774 ? Miscellaneous
 775
 776 ??      After I changed configure.in I get `Autoconf version X.Y.
 777         or higher is required for this script'.  What can I do?
 778
 779 {UD} You have to get the specified autoconf version (or a later one)
 780 from your favorite mirror of prep.ai.mit.edu.
 781
 782 ??      When I try to compile code which uses IPv6 headers and
 783         definitions on my Linux 2.x.y system I am in trouble.
 784         Nothing seems to work.
 785
 786 {UD} The problem is that IPv6 development still has not reached a
 787 point where the headers are stable.  There are still lots of
 788 incompatible changes made and the libc headers have to follow.
 789
 790 Also, make sure you have a suitably recent kernel.  As of the 970401
 791 snapshot, according to Philip Blundell <Philip.Blundell@pobox.com>, the
 792 required kernel version is at least 2.1.30.
 793
 794 \f
 795 Answers were given by:
 796 {UD} Ulrich Drepper, <drepper@cygnus.com>
 797 {DMT} David Mosberger-Tang, <davidm@AZStarNet.com>
 798 {RM} Roland McGrath, <roland@gnu.org>
 799 {AJ} Andreas Jaeger, <aj@arthur.rhein-neckar.de>
 800 {EY} Eric Youngdale, <eric@andante.jic.com>
 801 {PB} Phil Blundell, <Philip.Blundell@pobox.com>
 802 {MK} Mark Kettenis, <kettenis@phys.uva.nl>
 803 {ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu>
 804 {TK} Thorsten Kukuk, <kukuk@vt.uni-paderborn.de>
 805 \f
 806 Local Variables:
 807  mode:outline
 808  outline-regexp:"\\?"
 809 End: