diff options
Diffstat (limited to 'FAQ.in')
| -rw-r--r-- | FAQ.in | 787 |
1 files changed, 787 insertions, 0 deletions
@@ -0,0 +1,787 @@ + Frequently Asked Questions about the GNU C Library + +This document tries to answer questions a user might have when +installing and using glibc. Please make sure you read this before +sending questions or bug reports to the maintainers. + +The GNU C library is very complex. The installation process has not +been completely automated; there are too many variables. You can do +substantial damage to your system by installing the library +incorrectly. Make sure you understand what you are undertaking before +you begin. + +If you have any questions you think should be answered in this document, +please let me know. + + --drepper@cygnus.com + +? Compiling glibc + +?? What systems does the GNU C Library run on? + +{UD} This is difficult to answer. The file `README' lists the +architectures GNU libc was known to run on *at some time*. This does +not mean that it still can be compiled and run on them now. + +The systems glibc is known to work on as of this release, and most +probably in the future, are: + + *-*-gnu GNU Hurd + i[3456]86-*-linux-gnu Linux-2.0 on Intel + m68k-*-linux-gnu Linux-2.0 on Motorola 680x0 + alpha-*-linux-gnu Linux-2.0 on DEC Alpha + powerpc-*-linux-gnu Linux and MkLinux on PowerPC systems + sparc-*-linux-gnu Linux-2.0 on SPARC + sparc64-*-linux-gnu Linux-2.0 on UltraSPARC + +Ports to other Linux platforms are in development, and may in fact +work already, but no one has sent us success reports for them. +Currently no ports to other operating systems are underway, although a +few people have expressed interest. + +If you have a system not listed above (or in the `README' file) and +you are really interested in porting it, contact + + <bug-glibc@prep.ai.mit.edu> + +?? What compiler do I need to build GNU libc? + +{UD} You must use GNU CC to compile GNU libc. A lot of extensions of +GNU CC are used to increase portability and speed. + +GNU CC is found, like all other GNU packages, on + ftp://prep.ai.mit.edu/pub/gnu +and the many mirror sites. prep is always overloaded, so try to find +a local mirror first. + +You always should try to use the latest official release. Older +versions may not have all the features GNU libc requires. On most +supported platforms, 2.7.2.3 is the earliest version that works at all. + +?? When I try to compile glibc I get only error messages. + What's wrong? + +{UD} You definitely need GNU make to translate GNU libc. No +other make program has the needed functionality. + +We recommend version GNU make version 3.75. Versions 3.76 and 3.76.1 +have bugs which appear when building big projects like GNU libc. +Versions before 3.74 have bugs and/or are missing features. + +?? Do I need a special linker or archiver? + +{UD} You may be able to use your system linker, but GNU libc works +best with GNU binutils. + +On systems where the native linker does not support weak symbols you +will not get a fully ISO C compliant C library. Generally speaking +you should use the GNU binutils if they provide at least the same +functionality as your system's tools. + +Always get the newest release of GNU binutils available. Older +releases are known to have bugs that prevent a successful compilation. + +{ZW} As of release 2.1 a linker supporting symbol versions is +required. For Linux, get binutils-2.8.1.0.17 or later. Other systems +may have native linker support, but it's moot right now, because glibc +has not been ported to them. + +?? Do I need some more things to compile GNU C Library? + +{UD} Yes, there are some more :-). + +* GNU gettext. This package contains the tools needed to construct + `message catalog' files containing translated versions of system + messages. See ftp://prep.ai.mit.edu/pub/gnu or better any mirror + site. (We distribute compiled message catalogs, but they may not be + updated in patches.) + +* Some files depend on special tools. E.g., files ending in .gperf + need a `gperf' program. The GNU version (part of libg++) is known + to work while some vendor versions do not. + + You should not need these tools unless you change the source files. + +* When compiling for Linux, the header files of the Linux kernel must + be available to the compiler as <linux/*.h> and <asm/*.h>. + +* lots of disk space (~170MB for i?86-linux; more for RISC platforms). + +* plenty of time. Compiling just the shared and static libraries for + i?86-linux takes approximately 1h on an i586@133, or 2.5h on + i486@66, or 4.5h on i486@33. Multiply this by 1.5 or 2.0 if you + build profiling and/or the highly optimized version as well. For + Hurd systems times are much higher. + + You should avoid compiling in a NFS mounted filesystem. This is + very slow. + + James Troup <J.J.Troup@comp.brad.ac.uk> reports a compile time of + 45h34m for a full build (shared, static, and profiled) on + Atari Falcon (Motorola 68030 @ 16 Mhz, 14 Mb memory) and 22h48m + on Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory) + + If you have some more measurements let me know. + +?? When I run `nm -u libc.so' on the produced library I still + find unresolved symbols. Can this be ok? + +{UD} Yes, this is ok. There can be several kinds of unresolved +symbols: + +* magic symbols automatically generated by the linker. These have names + like __start_* and __stop_* + +* symbols starting with _dl_* come from the dynamic linker + +* symbols resolved by using libgcc.a + (__udivdi3, __umoddi3, or similar) + +* weak symbols, which need not be resolved at all (fabs for example) + +Generally, you should make sure you find a real program which produces +errors while linking before deciding there is a problem. + +??addon What are these `add-ons'? + +{UD} To avoid complications with export rules or external source +code some optional parts of the libc are distributed as separate +packages (e.g., the crypt package, see ?crypt). + +To use these packages as part of GNU libc, just unpack the tarfiles in +the libc source directory and tell the configuration script about them +using the --enable-add-ons option. If you give just --enable-add-ons +configure tries to find all the add-on packages in your source tree. +This may not work. If it doesn't, or if you want to select only a +subset of the add-ons, give a comma-separated list of the add-ons to +enable: + + configure --enable-add-ons=crypt,linuxthreads + +for example. + +Add-ons can add features (including entirely new shared libraries), +override files, provide support for additional architectures, and +just about anything else. The existing makefiles do most of the work; +only some few stub rules must be written to get everything running. + +?? My XXX kernel emulates a floating-point coprocessor for me. + Should I enable --with-fp? + +{ZW} An emulated FPU is just as good as a real one, as far as the C +library is concerned. You only need to say --without-fp if your +machine has no way to execute floating-point instructions. + +People who are interested in squeezing the last drop of performance +out of their machine may wish to avoid the trap overhead, but this is +far more trouble than it's worth: you then have to compile +*everything* this way, including the compiler's internal libraries +(libgcc.a for GNU C), because the calling conventions change. + +?? When compiling GNU libc I get lots of errors saying functions + in glibc are duplicated in libgcc. + +{EY} This is *exactly* the same problem that I was having. The +problem was due to the fact that configure didn't correctly detect +that the linker flag --no-whole-archive was supported in my linker. +In my case it was because I had run ./configure with bogus CFLAGS, and +the test failed. + +One thing that is particularly annoying about this problem is that +once this is misdetected, running configure again won't fix it unless +you first delete config.cache. + +{UD} Starting with glibc-2.0.3 there should be a better test to avoid +some problems of this kind. The setting of CFLAGS is checked at the +very beginning and if it is not usable `configure' will bark. + +?? What's the problem with configure --enable-omitfp? + +{AJ} When --enable-omitfp is set the libraries are built without frame +pointers. Some compilers produce buggy code for this model and +therefore we don't advise using it at the moment. + +If you use --enable-omitfp, you're on your own. If you encounter +problems with a library that was build this way, we advise you to +rebuild the library without --enable-omitfp. If the problem vanishes +consider tracking the problem down and report it as compiler failure. + +Since a library build with --enable-omitfp is undebuggable on most +systems, debuggable libraries are also built - you can use it by +appending "_g" to the library names. + +The compilation of these extra libraries and the compiler optimizations +slow down the build process and need more disk space. + +? Installation and configuration issues + +?? Can I replace the libc on my Linux system with GNU libc? + +{UD} You cannot replace any existing libc for Linux with GNU +libc. It is binary incompatible and therefore has a different major +version. You can, however, install it alongside your existing libc. + +For Linux there are three major libc versions: + libc-4 a.out libc + libc-5 original ELF libc + libc-6 GNU libc + +You can have any combination of these three installed. For more +information consult documentation for shared library handling. The +Makefiles of GNU libc will automatically generate the needed symbolic +links which the linker will use. + +?? How do I configure GNU libc so that the essential libraries + like libc.so go into /lib and the other into /usr/lib? + +{UD,AJ} Like all other GNU packages GNU libc is designed to use a base +directory and install all files relative to this. The default is +/usr/local, because this is safe (it will not damage the system if +installed there). If you wish to install GNU libc as the primary C +library on your system, set the base directory to /usr (i.e. run +configure --prefix=/usr <other_options>). Note that this can damage +your system; see ?safety for details. + +Some systems like Linux have a filesystem standard which makes a +difference between essential libraries and others. Essential +libraries are placed in /lib because this directory is required to be +located on the same disk partition as /. The /usr subtree might be +found on another partition/disk. If you configure for Linux with +--prefix=/usr, then this will be done automatically. + +To install the essential libraries which come with GNU libc in /lib on +systems other than Linux one must explicitly request it. Autoconf has +no option for this so you have to use a `configparms' file (see the +`INSTALL' file for details). It should contain: + +slibdir=/lib +sysconfdir=/etc + +The first line specifies the directory for the essential libraries, +the second line the directory for system configuration files. + +??safety How should I avoid damaging my system when I install GNU libc? + +{ZW} If you wish to be cautious, do not configure with --prefix=/usr. +If you don't specify a prefix, glibc will be installed in /usr/local, +where it will probably not break anything. (If you wish to be +certain, set the prefix to something like /usr/local/glibc2 which is +not used for anything.) + +The dangers when installing glibc in /usr are twofold: + +* glibc will overwrite the headers in /usr/include. Other C libraries + install a different but overlapping set of headers there, so the + effect will probably be that you can't compile anything. You need to + rename /usr/include out of the way first. (Do not throw it away; you + will then lose the ability to compile programs against your old libc.) + +* None of your old libraries, static or shared, can be used with a + different C library major version. For shared libraries this is not a + problem, because the filenames are different and the dynamic linker + will enforce the restriction. But static libraries have no version + information. You have to evacuate all the static libraries in + /usr/lib to a safe location. + +The situation is rather similar to the move from a.out to ELF which +long-time Linux users will remember. + +?? Do I need to use GNU CC to compile programs that will use the + GNU C Library? + +{ZW} In theory, no; the linker does not care, and the headers are +supposed to check for GNU CC before using its extensions to the C +language. + +However, there are currently no ports of glibc to systems where +another compiler is the default, so no one has tested the headers +extensively against another compiler. You may therefore encounter +difficulties. If you do, please report them as bugs. + +Also, in several places GNU extensions provide large benefits in code +quality. For example, the library has hand-optimized, inline assembly +versions of some string functions. These can only be used with GCC. +See ?string for details. + +??crypt When linking with the new libc I get unresolved symbols + `crypt' and `setkey'. Why aren't these functions in the + libc anymore? + +{UD} The US places restrictions on exporting cryptographic programs +and source code. Until this law gets abolished we cannot ship the +cryptographic functions together with glibc. + +The functions are available, as an add-on (see ?addon). People in the +US may get it from the same place they got GNU libc from. People +outside the US should get the code from ftp://ftp.ifi.uio.no/pub/gnu, +or another archive site outside the USA. The README explains how to +install the sources. + +If you already have the crypt code on your system the reason for the +failure is probably that you did not link with -lcrypt. The crypto +functions are in a separate library to make it possible to export GNU +libc binaries from the US. + +?? When I use GNU libc on my Linux system by linking against + the libc.so which comes with glibc all I get is a core dump. + +{UD} On Linux, gcc sets the dynamic linker to /lib/ld-linux.so.1 +unless the user specifies a -dynamic-linker argument. This is the +name of the libc5 dynamic linker, which does not work with glibc. + +For casual use of GNU libc you can just specify + -dynamic-linker=/lib/ld-linux.so.2 + +which is the glibc dynamic linker, on Linux systems. On other systems +the name is /lib/ld.so.1. + +To change your environment to use GNU libc for compiling you need to +change the `specs' file of your gcc. This file is normally found at + + /usr/lib/gcc-lib/<arch>/<version>/specs + +In this file you have to change a few things: + +- change `ld-linux.so.1' to `ld-linux.so.2' + +- remove all expression `%{...:-lgmon}'; there is no libgmon in glibc + +- fix a minor bug by changing %{pipe:-} to %| + +Here is what the gcc-2.7.2 specs file should look like when GNU libc +is installed at /usr: + +----------------------------------------------------------------------- +*asm: +%{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} + +*asm_final: +%| + +*cpp: +%{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} + +*cc1: +%{profile:-p} + +*cc1plus: + + +*endfile: +%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s + +*link: +-m elf_i386 %{shared:-shared} %{!shared: %{!ibcs: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}} %{static:-static}}} + +*lib: +%{!shared: %{pthread:-lpthread} %{profile:-lc_p} %{!profile: -lc}} + +*libgcc: +-lgcc + +*startfile: +%{!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} + +*switches_need_spaces: + + +*signed_char: +%{funsigned-char:-D__CHAR_UNSIGNED__} + +*predefines: +-D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) + +*cross_compile: +0 + +*multilib: +. ; + +----------------------------------------------------------------------- + +Things get a bit more complicated if you have GNU libc installed in +some other place than /usr, i.e., if you do not want to use it instead +of the old libc. In this case the needed startup files and libraries +are not found in the regular places. So the specs file must tell the +compiler and linker exactly what to use. + +Version 2.7.2.3 does and future versions of GCC will automatically +provide the correct specs. + +?? Looking through the shared libc file I haven't found the + functions `stat', `lstat', `fstat', and `mknod' and while + linking on my Linux system I get error messages. How is + this supposed to work? + +{RM} Believe it or not, stat and lstat (and fstat, and mknod) +are supposed to be undefined references in libc.so.6! Your problem is +probably a missing or incorrect /usr/lib/libc.so file; note that this +is a small text file now, not a symlink to libc.so.6. It should look +something like this: + +GROUP ( libc.so.6 ld.so.1 libc.a ) + +or in ix86/Linux and alpha/Linux: + +GROUP ( libc.so.6 ld-linux.so.2 libc.a ) + +?? How can I compile gcc 2.7.2.1 from the gcc source code using + glibc 2.x? + +{AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3 +or later. You should get at least gcc 2.7.2.3. All previous versions +had problems with glibc support. + +?? The `gencat' utility cannot process the catalog sources which + were used on my Linux libc5 based system. Why? + +{UD} The `gencat' utility provided with glibc complies to the XPG +standard. The older Linux version did not obey the standard, so they +are not compatible. + +To ease the transition from the Linux version some of the non-standard +features are also present in the `gencat' program of GNU libc. This +mainly includes the use of symbols for the message number and the automatic +generation of header files which contain the needed #defines to map the +symbols to integers. + +Here is a simple SED script to convert at least some Linux specific +catalog files to the XPG4 form: + +----------------------------------------------------------------------- +# Change catalog source in Linux specific format to standard XPG format. +# Ulrich Drepper <drepper@cygnus.com>, 1996. +# +/^\$ #/ { + h + s/\$ #\([^ ]*\).*/\1/ + x + s/\$ #[^ ]* *\(.*\)/\$ \1/ +} + +/^# / { + s/^# \(.*\)/\1/ + G + s/\(.*\)\n\(.*\)/\2 \1/ +} +----------------------------------------------------------------------- + +?? I have set up /etc/nis.conf, and the Linux libc 5 with NYS + works great. But the glibc NIS+ doesn't seem to work. + +{??} The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START +file for storing information about the NIS+ server and their public +keys, because the nis.conf file does not contain all the necessary +information. You have to copy a NIS_COLD_START file from a Solaris +client (the NIS_COLD_START file is byte order independent) or generate +it with nisinit from the nis-tools package (available at +http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html). + +?? After installing glibc name resolving doesn't work properly. + +{AJ} You probably should read the manual section describing +nsswitch.conf (just type `info libc "NSS Configuration File"'). +The NSS configuration file is usually the culprit. + +?? I have /usr/include/net and /usr/include/scsi as symlinks + into my Linux source tree. Is that wrong? + +{PB} This was necessary for libc5, but is not correct when using +glibc. Including the kernel header files directly in user programs +usually does not work (see ?kerhdr). glibc provides its own <net/*> +and <scsi/*> header files to replace them, and you may have to remove +any symlink that you have in place before you install glibc. However, +/usr/include/asm and /usr/include/linux should remain as they were. + +?? Programs like `logname', `top', `uptime' `users', `w' and + `who', show incorrect information about the (number of) + users on my system. Why? + +{MK} See ?getlog. + +?? After upgrading to glibc 2.1 with symbol versioning I get + errors about undefined symbols. What went wrong? + +{AJ} The problem is caused either by wrong program code or tools. In +the versioned libc a lot of symbols are now local that were global +symbols in previous versions. It seems that programs linked against +older versions often accidentally used libc global variables -- +something that should not happen. + +The only way to fix this is to recompile your program. Sorry, that's +the price you might have to pay once for quite a number of advantages +with symbol versioning. + +?? When I start the program XXX after upgrading the library + I get + XXX: Symbol `_sys_errlist' has different size in shared + object, consider re-linking + Why? What should I do? + +{UD} As the message says, relink the binary. The problem is that +a few symbols from the library can change in size and there is no way +to avoid this. _sys_errlist is a good example. Occasionally there are +new error numbers added to the kernel and this must be reflected at user +level, breaking programs that refer to them directly. + +Such symbols should normally not be used at all. There are mechanisms +to avoid using them. In the case of _sys_errlist, there is the +strerror() function which should _always_ be used instead. So the +correct fix is to rewrite that part of the application. + +In some situations (especially when testing a new library release) it +might be possible that a symbol changed size when that should not have +happened. So in case of doubt report such a warning message as a +problem. + +? Source and binary incompatibilities, and what to do about them + +?? I expect GNU libc to be 100% source code compatible with + the old Linux based GNU libc. Why isn't it like this? + +{DMT,UD} Not every extension in Linux libc's history was well +thought-out. In fact it had a lot of problems with standards compliance +and with cleanliness. With the introduction of a new version number these +errors can now be corrected. Here is a list of the known source code +incompatibilities: + +* _GNU_SOURCE: glibc does not make the GNU extensions available + automatically. If a program depends on GNU extensions or some + other non-standard functionality, it is necessary to compile it + with the C compiler option -D_GNU_SOURCE, or better, to put + `#define _GNU_SOURCE' at the beginning of your source files, before + any C library header files are included. This difference normally + manifests itself in the form of missing prototypes and/or data type + definitions. Thus, if you get such errors, the first thing you + should do is try defining _GNU_SOURCE and see if that makes the + problem go away. + + For more information consult the file `NOTES' in the GNU C library + sources. + +* reboot(): GNU libc sanitizes the interface of reboot() to be more + compatible with the interface used on other OSes. reboot() as + implemented in glibc takes just one argument. This argument + corresponds to the third argument of the Linux reboot system call. + That is, a call of the form reboot(a, b, c) needs to be changed into + reboot(c). Beside this the header <sys/reboot.h> defines the needed + constants for the argument. These RB_* constants should be used + instead of the cryptic magic numbers. + +* swapon(): the interface of this function didn't change, but the + prototype is in a separate header file <sys/swap.h>. This header + file also provides the SWAP_* constants defined by <linux/swap.h>; + you should use them for the second argument to swapon(). + +* errno: If a program uses the variable "errno", then it _must_ + include <errno.h>. The old libc often (erroneously) declared this + variable implicitly as a side-effect of including other libc header + files. glibc is careful to avoid such namespace pollution, which, + in turn, means that you really need to include the header files that + you depend on. This difference normally manifests itself in the + form of the compiler complaining about references to an undeclared + symbol "errno". + +* Linux-specific syscalls: All Linux system calls now have appropriate + library wrappers and corresponding declarations in various header files. + This is because the syscall() macro that was traditionally used to + work around missing syscall wrappers are inherently non-portable and + error-prone. The following table lists all the new syscall stubs, + the header-file declaring their interface and the system call name. + + syscall name: wrapper name: declaring header file: + ------------- ------------- ---------------------- + bdflush bdflush <sys/kdaemon.h> + syslog ksyslog_ctl <sys/klog.h> + +* lpd: Older versions of lpd depend on a routine called _validuser(). + The library does not provide this function, but instead provides + __ivaliduser() which has a slightly different interface. Simply + upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD + lpd is known to be working). + +* resolver functions/BIND: like on many other systems the functions of + the resolver library are not included in libc itself. There is a + separate library libresolv. If you get undefined symbol errors for + symbols starting with `res_*' simply add -lresolv to your linker + command line. + +* the `signal' function's behavior corresponds to the BSD semantic and + not the SysV semantic as it was in libc-5. The interface on all GNU + systems shall be the same and BSD is the semantic of choice. To use + the SysV behavior simply use `sysv_signal', or define _XOPEN_SOURCE. + See ?signal for details. + +??getlog Why does getlogin() always return NULL on my Linux box? + +{UD} The GNU C library has a format for the UTMP and WTMP file which +differs from what your system currently has. It was extended to +fulfill the needs of the next years when IPv6 is introduced. The +record size is different and some fields have different positions. +The files written by functions from the one library cannot be read by +functions from the other library. Sorry, but this is what a major +release is for. It's better to have a cut now than having no means to +support the new techniques later. + +{MK} There is however a (partial) solution for this problem. Please +take a look at the file `README.utmpd'. + +?? Where are the DST_* constants found in <sys/time.h> on many + systems? + +{UD} These constants come from the old BSD days and are not used +anymore (libc5 does not actually implement the handling although the +constants are defined). + +Instead GNU libc contains zone database support and compatibility code +for POSIX TZ environment variable handling. + +?? The prototypes for `connect', `accept', `getsockopt', + `setsockopt', `getsockname', `getpeername', `send', + `sendto', and `recvfrom' are different in GNU libc from + any other system I saw. This is a bug, isn't it? + +{UD} No, this is no bug. This version of GNU libc already follows the +new Single Unix specifications (and I think the POSIX.1g draft which +adopted the solution). The type for a parameter describing a size is +now `socklen_t', a new type. + +??kerhdr On Linux I've got problems with the declarations in Linux + kernel headers. + +{UD,AJ} On Linux, the use of kernel headers is reduced to the minimum. +This gives Linus the ability to change the headers more freely. Also, +user programs are now insulated from changes in the size of kernel +data structures. + +For example, the sigset_t type is 32 or 64 bits wide in the kernel. +In glibc it is 1024 bits wide. This guarantees that when the kernel +gets a bigger sigset_t (for POSIX.1e realtime support, say) user +programs will not have to be recompiled. Consult the header files for +more information about the changes. + +Therefore you shouldn't include Linux kernel header files directly if +glibc has defined a replacement. Otherwise you might get undefined +results because of type conflicts. + +?? I don't include any kernel headers myself but the compiler + still complains about redeclarations of types in the kernel + headers. + +{UD} The kernel headers before Linux 2.1.61 don't work correctly with +glibc. Compiling C programs is possible in most cases but C++ +programs have (due to the change of the name lookups for `struct's) +problems. One prominent example is `struct fd_set'. + +There might be some problems left but 2.1.61 fixes most of the known +ones. See the BUGS file for other known problems. + +??signal Why don't signals interrupt system calls anymore? + +{ZW} By default GNU libc uses the BSD semantics for signal(), +unlike Linux libc 5 which used System V semantics. This is partially +for compatibility with other systems and partially because the BSD +semantics tend to make programming with signals easier. + +There are three differences: + +* BSD-style signals that occur in the middle of a system call do not + affect the system call; System V signals cause the system call to + fail and set errno to EINTR. + +* BSD signal handlers remain installed once triggered. System V signal + handlers work only once, so one must reinstall them each time. + +* A BSD signal is blocked during the execution of its handler. In other + words, a handler for SIGCHLD (for example) does not need to worry about + being interrupted by another SIGCHLD. It may, however, be interrupted + by other signals. + +There is general consensus that for `casual' programming with signals, the +BSD semantics are preferable. You don't need to worry about system calls +returning EINTR, and you don't need to worry about the race conditions +associated with one-shot signal handlers. + +If you are porting an old program that relies on the old semantics, you can +quickly fix the problem by changing signal() to sysv_signal() throughout. +Alternatively, define _XOPEN_SOURCE before including <signal.h>. + +For new programs, the sigaction() function allows you to specify precisely +how you want your signals to behave. All three differences listed above are +individually switchable on a per-signal basis with this function. + +If all you want is for one specific signal to cause system calls to fail +and return EINTR (for example, to implement a timeout) you can do this with +siginterrupt(). + + +??string I've got errors compiling code that uses certain string + functions. Why? + +{AJ} glibc 2.1 has special string functions that are faster +than the normal library functions. Some of the functions are +implemented as inline functions and others as macros. + +The optimized string functions are only used when compiling with +optimizations (-O1 or higher). The behavior can be changed with two +feature macros: + +* __NO_STRING_INLINES: Don't do any string optimizations. +* __USE_STRING_INLINES: Use assembly language inline functions (might + increase code size dramatically). + +Since some of these string functions are now additionally defined as +macros, code like "char *strncpy();" doesn't work anymore (and is +unnecessary, since <string.h> has the necessary declarations). Either +change your code or define __NO_STRING_INLINES. + +{UD} Another problem in this area is that gcc still has problems on +machines with very few registers (e.g., ix86). The inline assembler +code can require almost all the registers and the register allocator +cannot always handle this situation. + +One can disable the string optimizations selectively. Instead of writing + + cp = strcpy (foo, "lkj"); + +one can write + + cp = (strcpy) (foo, "lkj"); + +This disables the optimization for that specific call. + +? Miscellaneous + +?? After I changed configure.in I get `Autoconf version X.Y. + or higher is required for this script'. What can I do? + +{UD} You have to get the specified autoconf version (or a later one) +from your favorite mirror of prep.ai.mit.edu. + +?? When I try to compile code which uses IPv6 headers and + definitions on my Linux 2.x.y system I am in trouble. + Nothing seems to work. + +{UD} The problem is that IPv6 development still has not reached a +point where the headers are stable. There are still lots of +incompatible changes made and the libc headers have to follow. + +Also, make sure you have a suitably recent kernel. As of the 970401 +snapshot, according to Philip Blundell <philb@gnu.ai.mit.edu>, the +required kernel version is 2.1.30. + + +Answers were given by: +{UD} Ulrich Drepper, <drepper@cygnus.com> +{DMT} David Mosberger-Tang, <davidm@AZStarNet.com> +{RM} Roland McGrath, <roland@gnu.org> +{AJ} Andreas Jaeger, <aj@arthur.rhein-neckar.de> +{EY} Eric Youngdale, <eric@andante.jic.com> +{PB} Phil Blundell, <Philip.Blundell@pobox.com> +{MK} Mark Kettenis, <kettenis@phys.uva.nl> +{ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu> + +Local Variables: + mode:outline + outline-regexp:"\\?" +End: |