788 lines
31 KiB
Plaintext
788 lines
31 KiB
Plaintext
|
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:
|