1312 lines
56 KiB
Plaintext
1312 lines
56 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.x on Intel
|
||
m68k-*-linux-gnu Linux-2.x on Motorola 680x0
|
||
alpha-*-linux-gnu Linux-2.x on DEC Alpha
|
||
powerpc-*-linux-gnu Linux and MkLinux on PowerPC systems
|
||
sparc-*-linux-gnu Linux-2.x on SPARC
|
||
sparc64-*-linux-gnu Linux-2.x on UltraSPARC
|
||
arm-*-none ARM standalone systems
|
||
arm-*-linux Linux-2.x on ARM
|
||
arm-*-linuxaout Linux-2.x on ARM using a.out binaries
|
||
|
||
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@gnu.org>
|
||
|
||
?? 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://ftp.gnu.org/pub/gnu
|
||
|
||
and the many mirror sites. ftp.gnu.org is always overloaded, so try to find
|
||
a local mirror first.
|
||
|
||
You should always try to use the latest official release. Older versions
|
||
may not have all the features GNU libc requires. The current releases of
|
||
egcs (1.0.3 and 1.1) and GNU CC (2.8.1) should work with the GNU C library
|
||
(for powerpc see ?powerpc; for ARM see ?arm).
|
||
|
||
{ZW} You may have problems if you try to mix code compiled with
|
||
EGCS and with GCC 2.8.1. See ?exception for details.
|
||
|
||
?? 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 or 3.77. Versions before 3.75
|
||
have bugs and/or are missing features. Version 3.76 has bugs which
|
||
appear when building big projects like GNU libc. 3.76.1 appears to work but
|
||
some people have reported problems. If you build GNU make 3.77 from source,
|
||
please read ?make first.
|
||
|
||
?? Do I need a special linker or assembler?
|
||
|
||
{ZW} If you want a shared library, you need a linker and assembler that
|
||
understand all the features of ELF, including weak and versioned symbols.
|
||
The static library can be compiled with less featureful tools, but lacks key
|
||
features such as NSS.
|
||
|
||
For Linux or Hurd, you want binutils 2.8.1.0.23, 2.9.1, or 2.9.1.0.15 or
|
||
higher. These are the only versions we've tested and found reliable. Other
|
||
versions after 2.8.1.0.23 may work but we don't recommend them, especially
|
||
not when C++ is involved. Earlier versions do not work at all.
|
||
|
||
Other operating systems may come with system tools that have all the
|
||
necessary features, but this is moot because glibc hasn't been ported to
|
||
them.
|
||
|
||
??powerpc Which compiler should I use for powerpc?
|
||
|
||
{GK} You want to use egcs 1.1 or later (together with the right versions
|
||
of all the other tools, of course).
|
||
|
||
In fact, egcs 1.1 has a bug that causes linuxthreads to be
|
||
miscompiled, resulting in segmentation faults when using condition
|
||
variables. There is a temporary patch at:
|
||
|
||
<http://discus.anu.edu.au/~geoffk/egcs-3.diff>
|
||
|
||
Later versions of egcs may fix this problem.
|
||
|
||
??arm Which tools should I use for ARM?
|
||
|
||
{PB} You should use egcs 1.1 or a later version. For ELF systems some
|
||
changes are needed to the compiler; a patch against egcs-1.1.x can be found
|
||
at:
|
||
|
||
<ftp://ftp.netwinder.org/users/p/philb/egcs-1.1.1pre2-diff-981126>
|
||
|
||
Binutils 2.9.1.0.16 or later is also required.
|
||
|
||
?? Do I need some more things to compile the 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://ftp.gnu.org/pub/gnu or better any mirror
|
||
site. (We distribute compiled message catalogs, but they may not be
|
||
updated in patches.)
|
||
|
||
* Some files are built with special tools. E.g., files ending in .gperf
|
||
need a `gperf' program. The GNU version (now available in a separate
|
||
package, formerly only as 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.
|
||
|
||
* Perl 5 is needed if you wish to test an installation of GNU libc
|
||
as the primary C library.
|
||
|
||
* 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,
|
||
as much as 400MB).
|
||
|
||
* 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 Jan Barte
|
||
<yann@plato.uni-paderborn.de> reports 22h48m on Atari TT030
|
||
(Motorola 68030 @ 32 Mhz, 34 Mb memory)
|
||
|
||
If you have some more measurements let me know.
|
||
|
||
?? What version of the Linux kernel headers should be used?
|
||
|
||
{AJ,UD} The headers from the most recent Linux kernel should be used. The
|
||
headers used while compiling the GNU C library and the kernel binary used
|
||
when using the library do not need to match. The GNU C library runs without
|
||
problems on kernels that are older than the kernel headers used. The other
|
||
way round (compiling the GNU C library with old kernel headers and running
|
||
on a recent kernel) does not necessarily work. For example you can't use
|
||
new kernel features when using old kernel headers for compiling the GNU C
|
||
library.
|
||
|
||
{ZW} Even if you are using a 2.0 kernel on your machine, we recommend you
|
||
compile GNU libc with 2.2 kernel headers. That way you won't have to
|
||
recompile libc if you ever upgrade to kernel 2.2. To tell libc which
|
||
headers to use, give configure the --with-headers switch
|
||
(e.g. --with-headers=/usr/src/linux-2.2.0/include).
|
||
|
||
Note that you must configure the 2.2 kernel if you do this, otherwise libc
|
||
will be unable to find <linux/version.h>. Just change the current directory
|
||
to the root of the 2.2 tree and do `make include/linux/version.h'.
|
||
|
||
?? The compiler hangs while building iconvdata modules. What's
|
||
wrong?
|
||
|
||
{ZW} This is a problem with old versions of GCC. Initialization of large
|
||
static arrays is very slow. The compiler will eventually finish; give it
|
||
time.
|
||
|
||
The problem is fixed in egcs 1.1 but not in earlier releases.
|
||
|
||
?? 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
|
||
|
||
* 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.
|
||
|
||
?? Why do I get messages about missing thread functions when I use
|
||
librt? I don't even use threads.
|
||
|
||
{UD} In this case you probably mixed up your installation. librt uses
|
||
threads internally and has implicit references to the thread library.
|
||
Normally these references are satisfied automatically but if the thread
|
||
library is not in the expected place you must tell the linker where it is.
|
||
When using GNU ld it works like this:
|
||
|
||
gcc -o foo foo.c -Wl,-rpath-link=/some/other/dir -lrt
|
||
|
||
The `/some/other/dir' should contain the thread library. `ld' will use the
|
||
given path to find the implicitly referenced library while not disturbing
|
||
any other link path.
|
||
|
||
?? 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.
|
||
|
||
?? I get failures during `make check'. What shall I do?
|
||
|
||
{AJ} The testsuite should compile and run cleanly on your system, every
|
||
failure should be looked into. Depending on the failure I wouldn't advise
|
||
installing the library at all.
|
||
|
||
You should consider using the `glibcbug' script to report the failure,
|
||
providing as much detail as possible. If you run a test directly, please
|
||
remember to set up the environment correctly. You want to test the compiled
|
||
library - and not your installed one. The best way is to copy the exact
|
||
command line which failed and run the test from the subdirectory for this
|
||
test in the sources.
|
||
|
||
There are some failures which are not directly related to the GNU libc:
|
||
- Some compiler produce buggy code. The egcs 1.1 release should be ok. gcc
|
||
2.8.1 might cause some failures, gcc 2.7.2.x is so buggy, that explicit
|
||
checks have been used so that you can't build with it.
|
||
- The kernel might have bugs. For example on Linux/Alpha 2.0.34 the
|
||
floating point handling has quite a number of bugs and therefore most of
|
||
the test cases in the math subdirectory will fail. Linux 2.2 has
|
||
fixes for the floating point support on Alpha.
|
||
|
||
?? What is symbol versioning good for? Do I need it?
|
||
|
||
{AJ} Symbol versioning solves problems that are related to interface
|
||
changes. One version of an interface might have been introduced in a
|
||
previous version of the GNU C library but the interface or the semantics of
|
||
the function has been changed in the meantime. For binary compatibility
|
||
with the old library, a newer library needs to still have the old interface
|
||
for old programs. On the other hand new programs should use the new
|
||
interface. Symbol versioning is the solution for this problem. The GNU
|
||
libc version 2.1 uses by default symbol versioning if the binutils support
|
||
it.
|
||
|
||
We don't advise to build without symbol versioning since you lose binary
|
||
compatibility if you do - for ever! The binary compatibility you lose is
|
||
not only against the previous version of the GNU libc (version 2.0) but also
|
||
against future versions.
|
||
|
||
|
||
? 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 to the linker
|
||
--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. When linking via gcc, you've got to add
|
||
-Wl,--dynamic-linker=/lib/ld-linux.so.2
|
||
|
||
to the gcc command line.
|
||
|
||
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 libc_nonshared.a )
|
||
|
||
??exception When I run an executable on one system which I compiled on
|
||
another, I get dynamic linker errors. Both systems have the same
|
||
version of glibc installed. What's wrong?
|
||
|
||
{ZW} Glibc on one of these systems was compiled with gcc 2.7 or 2.8, the
|
||
other with egcs (any version). Egcs has functions in its internal
|
||
`libgcc.a' to support exception handling with C++. They are linked into
|
||
any program or dynamic library compiled with egcs, whether it needs them or
|
||
not. Dynamic libraries then turn around and export those functions again
|
||
unless special steps are taken to prevent them.
|
||
|
||
When you link your program, it resolves its references to the exception
|
||
functions to the ones exported accidentally by libc.so. That works fine as
|
||
long as libc has those functions. On the other system, libc doesn't have
|
||
those functions because it was compiled by gcc 2.8, and you get undefined
|
||
symbol errors. The symbols in question are named things like
|
||
`__register_frame_info'.
|
||
|
||
For glibc 2.0, the workaround is to not compile libc with egcs. We've also
|
||
incorporated a patch which should prevent the EH functions sneaking into
|
||
libc. It doesn't matter what compiler you use to compile your program.
|
||
|
||
For glibc 2.1, we've chosen to do it the other way around: libc.so
|
||
explicitly provides the EH functions. This is to prevent other shared
|
||
libraries from doing it. You must therefore compile glibc 2.1 with EGCS
|
||
unless you don't care about ever importing binaries from other systems.
|
||
Again, it doesn't matter what compiler you use for your programs.
|
||
|
||
?? 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.
|
||
But you should get at least gcc 2.8.1 or egcs 1.0.2 (or later versions)
|
||
instead.
|
||
|
||
?? 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/
|
||
}
|
||
-----------------------------------------------------------------------
|
||
|
||
?? Programs using libc have their messages translated, but other
|
||
behavior is not localized (e.g. collating order); why?
|
||
|
||
{ZW} Translated messages are automatically installed, but the locale
|
||
database that controls other behaviors is not. You need to run localedef to
|
||
install this database, after you have run `make install'. For example, to
|
||
set up the French Canadian locale, simply issue the command
|
||
|
||
localedef -i fr_CA -f ISO-8859-1 fr_CA
|
||
|
||
Please see localedata/README in the source tree for further details.
|
||
|
||
?? 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.
|
||
|
||
{TK} 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
|
||
|
||
?? I have killed ypbind to stop using NIS, but glibc
|
||
continues using NIS.
|
||
|
||
{TK} For faster NIS lookups, glibc uses the /var/yp/binding/ files from
|
||
ypbind. ypbind 3.3 and older versions don't always remove these files, so
|
||
glibc will continue to use them. Other BSD versions seem to work correctly.
|
||
Until ypbind 3.4 is released, you can find a patch at
|
||
|
||
ftp://ftp.kernel.org/pub/linux/utils/net/NIS/ypbind-3.3-glibc4.diff.gz
|
||
|
||
?? Under Linux/Alpha, I always get "do_ypcall: clnt_call:
|
||
RPC: Unable to receive; errno = Connection refused" when using NIS.
|
||
|
||
{TK} You need a ypbind version which is 64bit clean. Some versions are not
|
||
64bit clean. A 64bit clean implementation is ypbind-mt. For ypbind 3.3,
|
||
you need the patch from ftp.kernel.org (See the previous question). I don't
|
||
know about other versions.
|
||
|
||
|
||
?? 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.
|
||
|
||
|
||
?? How do I create the databases for NSS?
|
||
|
||
{AJ} If you have an entry "db" in /etc/nsswitch.conf you should also create
|
||
the database files. The glibc sources contain a Makefile which does the
|
||
necessary conversion and calls to create those files. The file is
|
||
`db-Makefile' in the subdirectory `nss' and you can call it with `make -f
|
||
db-Makefile'. Please note that not all services are capable of using a
|
||
database. Currently passwd, group, ethers, protocol, rpc, services shadow
|
||
and netgroup are implemented.
|
||
|
||
?? 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.
|
||
|
||
?? What do I need for C++ development?
|
||
|
||
{HJ,AJ} You need either egcs 1.1 which comes directly with libstdc++ or
|
||
gcc-2.8.1 together with libstdc++ 2.8.1.1. egcs 1.1 has the better C++
|
||
support and works directly with glibc 2.1. If you use gcc-2.8.1 with
|
||
libstdc++ 2.8.1.1, you need to modify libstdc++ a bit. A patch is available
|
||
as:
|
||
ftp://alpha.gnu.org/gnu/libstdc++-2.8.1.1-glibc2.1-diff.gz
|
||
|
||
Please note that libg++ 2.7.2 (and the Linux Versions 2.7.2.x) doesn't work
|
||
very well with the GNU C library due to vtable thunks. If you're upgrading
|
||
from glibc 2.0.x to 2.1 you have to recompile libstdc++ since the library
|
||
compiled for 2.0 is not compatible due to the new Large File Support (LFS)
|
||
in version 2.1.
|
||
|
||
{UD} But since in the case of a shared libstdc++ the version numbers should
|
||
be different existing programs will continue to work.
|
||
|
||
?? Even statically linked programs need some shared libraries
|
||
which is not acceptable for me. What can I do?
|
||
|
||
{AJ} NSS (for details just type `info libc "Name Service Switch"') won't
|
||
work properly without shared libraries. NSS allows using different services
|
||
(e.g. NIS, files, db, hesiod) by just changing one configuration file
|
||
(/etc/nsswitch.conf) without relinking any programs. The only disadvantage
|
||
is that now static libraries need to access shared libraries. This is
|
||
handled transparently by the GNU C library.
|
||
|
||
A solution is to configure glibc with --enable-static-nss. In this case you
|
||
can create a static binary that will use only the services dns and files
|
||
(change /etc/nsswitch.conf for this). You need to link explicitly against
|
||
all these services. For example:
|
||
|
||
gcc -static test-netdb.c -o test-netdb.c \
|
||
-lc -lnss_files -lnss_dns -lresolv
|
||
|
||
The problem with this approach is that you've got to link every static
|
||
program that uses NSS routines with all those libraries.
|
||
|
||
{UD} In fact, one cannot say anymore that a libc compiled with this
|
||
option is using NSS. There is no switch anymore. Therefore it is
|
||
*highly* recommended *not* to use --enable-static-nss since this makes
|
||
the behaviour of the programs on the system inconsistent.
|
||
|
||
?? I just upgraded my Linux system to glibc and now I get
|
||
errors whenever I try to link any program.
|
||
|
||
{ZW} This happens when you have installed glibc as the primary C library but
|
||
have stray symbolic links pointing at your old C library. If the first
|
||
`libc.so' the linker finds is libc 5, it will use that. Your program
|
||
expects to be linked with glibc, so the link fails.
|
||
|
||
The most common case is that glibc put its `libc.so' in /usr/lib, but there
|
||
was a `libc.so' from libc 5 in /lib, which gets searched first. To fix the
|
||
problem, just delete /lib/libc.so. You may also need to delete other
|
||
symbolic links in /lib, such as /lib/libm.so if it points to libm.so.5.
|
||
|
||
{AJ} The perl script test-installation.pl which is run as last step during
|
||
an installation of glibc that is configured with --prefix=/usr should help
|
||
detect these situations. If the script reports problems, something is
|
||
really screwed up.
|
||
|
||
?? When I use nscd the machine freezes.
|
||
|
||
{UD} You cannot use nscd with Linux 2.0.*. There is functionality missing
|
||
in the kernel and work-arounds are not suitable. Besides, some parts of the
|
||
kernel are too buggy when it comes to using threads.
|
||
|
||
If you need nscd, you have to use at least a 2.1 kernel.
|
||
|
||
Note that I have at this point no information about any other platform.
|
||
|
||
?? I need lots of open files. What do I have to do?
|
||
|
||
{AJ} This is at first a kernel issue. The kernel defines limits with
|
||
OPEN_MAX the number of simultaneous open files and with FD_SETSIZE the
|
||
number of used file descriptors. You need to change these values in your
|
||
kernel and recompile the kernel so that the kernel allows to use more open
|
||
files. You don't necessarily need to recompile the GNU C library since the
|
||
only place where OPEN_MAX and FD_SETSIZE is really needed in the library
|
||
itself is the size of fd_set which is used by select.
|
||
|
||
The GNU C library is now (nearly) select free. This means it internally has
|
||
no limits imposed by the `fd_set' type. Instead almost all places where the
|
||
functionality is needed the `poll' function is used.
|
||
|
||
If you increase the number of file descriptors in the kernel you don't need
|
||
to recompile the C library. The remaining select calls are in the RPC code.
|
||
If your RPC daemons don't need more than FD_SETSIZE file descriptors, you
|
||
don't need to change anything at all.
|
||
|
||
{UD} You can always get the maximum number of file descriptors a process is
|
||
allowed to have open at any time using
|
||
|
||
number = sysconf (_SC_OPEN_MAX);
|
||
|
||
This will work even if the kernel limits change.
|
||
|
||
?? How do I get the same behavior on parsing /etc/passwd and
|
||
/etc/group as I have with libc5 ?
|
||
|
||
{TK} The name switch setup in /etc/nsswitch.conf selected by most Linux
|
||
distributions does not support +/- and netgroup entries in the files like
|
||
/etc/passwd. Though this is the preferred setup some people might have
|
||
setups coming over from the libc5 days where it was the default to recognize
|
||
lines like this. To get back to the old behaviour one simply has to change
|
||
the rules for passwd, group, and shadow in the nsswitch.conf file as
|
||
follows:
|
||
|
||
passwd: compat
|
||
group: compat
|
||
shadow: compat
|
||
|
||
passwd_compat: nis
|
||
group_compat: nis
|
||
shadow_compat: nis
|
||
|
||
?? What needs to be recompiled when upgrading from glibc 2.0 to glibc
|
||
2.1?
|
||
|
||
{AJ,CG} If you just upgrade the glibc from 2.0.x (x <= 7) to 2.1, binaries
|
||
that have been linked against glibc 2.0 will continue to work.
|
||
|
||
If you compile your own binaries against glibc 2.1, you also need to
|
||
recompile some other libraries. The problem is that libio had to be
|
||
changed and therefore libraries that are based or depend on the libio
|
||
of glibc, e.g. ncurses or slang, need to be recompiled. If you
|
||
experience strange segmentation faults in your programs linked against
|
||
glibc 2.1, you might need to recompile your libraries.
|
||
|
||
Another problem is that older binaries that were linked statically against
|
||
glibc 2.0 will reference the older nss modules (libnss_files.so.1 instead of
|
||
libnss_files.so.2), so don't remove them. Also, the old glibc-2.0 compiled
|
||
static libraries (libfoo.a) which happen to depend on the older libio
|
||
behavior will be broken by the glibc 2.1 upgrade. We plan to produce a
|
||
compatibility library that people will be able to link in if they want
|
||
to compile a static library generated against glibc 2.0 into a program
|
||
on a glibc 2.1 system. You just add -lcompat and you should be fine.
|
||
|
||
The glibc-compat add-on will provide the libcompat.a library, the older
|
||
nss modules, and a few other files. Together, they should make it
|
||
possible to do development with old static libraries on a glibc 2.1
|
||
system. This add-on is still in development. You can get it from <URL>
|
||
but please keep in mind that it is experimental.
|
||
|
||
? 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 `login/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. For former is very much preferred
|
||
(see ?tzdb).
|
||
|
||
?? 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 and 2.0.32 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/2.0.32 fix 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 additionally 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.
|
||
|
||
?? I get compiler messages "Initializer element not constant" with
|
||
stdin/stdout/stderr. Why?
|
||
|
||
{RM,AJ} Constructs like:
|
||
static FILE *InPtr = stdin;
|
||
|
||
lead to this message. This is correct behaviour with glibc since stdin is
|
||
not a constant expression. Please note that a strict reading of ISO C does
|
||
not allow above constructs.
|
||
|
||
One of the advantages of this is that you can assign to stdin, stdout, and
|
||
stderr just like any other global variable (e.g. `stdout = my_stream;'),
|
||
which can be very useful with custom streams that you can write with libio
|
||
(but beware this is not necessarily portable). The reason to implement it
|
||
this way were versioning problems with the size of the FILE structure.
|
||
|
||
To fix those programs you've got to initialize the variable at run time.
|
||
This can be done, e.g. in main, like:
|
||
|
||
static FILE *InPtr;
|
||
int main(void)
|
||
{
|
||
InPtr = stdin;
|
||
}
|
||
|
||
or by constructors (beware this is gcc specific):
|
||
|
||
static FILE *InPtr;
|
||
static void inPtr_construct (void) __attribute__((constructor));
|
||
static void inPtr_construct (void) { InPtr = stdin; }
|
||
|
||
|
||
?? I can't compile with gcc -traditional (or
|
||
-traditional-cpp). Why?
|
||
|
||
{AJ} glibc2 does break -traditional and -traditonal-cpp - and will continue
|
||
to do so. For example constructs of the form:
|
||
|
||
enum {foo
|
||
#define foo foo
|
||
}
|
||
|
||
are useful for debugging purposes (you can use foo with your debugger that's
|
||
why we need the enum) and for compatibility (other systems use defines and
|
||
check with #ifdef).
|
||
|
||
?? I get some errors with `gcc -ansi'. Isn't glibc ANSI compatible?
|
||
|
||
{AJ} The GNU C library is compatible with the ANSI/ISO C standard. If
|
||
you're using `gcc -ansi', the glibc includes which are specified in the
|
||
standard follow the standard. The ANSI/ISO C standard defines what has to be
|
||
in the include files - and also states that nothing else should be in the
|
||
include files (btw. you can still enable additional standards with feature
|
||
flags).
|
||
|
||
The GNU C library is conforming to ANSI/ISO C - if and only if you're only
|
||
using the headers and library functions defined in the standard.
|
||
|
||
?? I can't access some functions anymore. nm shows that they do
|
||
exist but linking fails nevertheless.
|
||
|
||
{AJ} With the introduction of versioning in glibc 2.1 it is possible to
|
||
export only those identifiers (functions, variables) that are really needed
|
||
by application programs and by other parts of glibc. This way a lot of
|
||
internal interfaces are now hidden. nm will still show those identifiers
|
||
but marking them as internal. ISO C states that identifiers beginning with
|
||
an underscore are internal to the libc. An application program normally
|
||
shouldn't use those internal interfaces (there are exceptions,
|
||
e.g. __ivaliduser). If a program uses these interfaces, it's broken. These
|
||
internal interfaces might change between glibc releases or dropped
|
||
completely.
|
||
|
||
?? When using the db-2 library which comes with glibc is used in
|
||
the Perl db modules the testsuite is not passed. This did not
|
||
happen with db-1, gdbm, or ndbm.
|
||
|
||
{UD} You are using an outdated copy of the DB_File Perl module. In fact db-2
|
||
finally removed the handling of zero-sized keys which was one of the features
|
||
tested by the old Perl testsuite and therefore you see an error. But this
|
||
never was documented and guaranteed, only broken programs used this feature.
|
||
|
||
Consequently db-2 does not need to support this feature and instead signals
|
||
an error which leads to easier debugging. The DB_File module maintainer
|
||
Paul Marquess <pmarquess@bfsec.bt.co.uk> acknowledged this change and fixed
|
||
the testsuite so that if you use DB_File v1.60 or later you should not have
|
||
any more problems with db-2.
|
||
|
||
?? The pow() inline function I get when including <math.h> is broken.
|
||
I get segmentation faults when I run the program.
|
||
|
||
{UD} Nope, the implementation is correct. The problem is with egcs version
|
||
prior to 1.1. I.e., egcs 1.0 to 1.0.3 are all broken (at least on Intel).
|
||
If you have to use this compiler you must define __NO_MATH_INLINES before
|
||
including <math.h> to prevent the inline functions from being used. egcs 1.1
|
||
fixes the problem. I don't know about gcc 2.8 and 2.8.1.
|
||
|
||
?? The sys/sem.h file lacks the definition of `union semun'.
|
||
|
||
{UD} Nope. This union has to be provided by the user program. Former glibc
|
||
versions defined this but it was an error since it does not make much sense
|
||
when thinking about it. The standards describing the System V IPC functions
|
||
define it this way and therefore programs must be adopted.
|
||
|
||
?? Why has <netinet/ip_fw.h> disappeared?
|
||
|
||
{AJ} The corresponding Linux kernel data structures and constants are
|
||
totally different in Linux 2.0 and Linux 2.2. This situation has to be
|
||
taken care in user programs using the firewall structures and therefore
|
||
those programs (ipfw is AFAIK the only one) should deal with this problem
|
||
themselves.
|
||
|
||
?? I get floods of warnings when I use -Wconversion and include
|
||
<string.h> or <math.h>.
|
||
|
||
{ZW} <string.h> and <math.h> intentionally use prototypes to override
|
||
argument promotion. -Wconversion warns about all these. You can safely
|
||
ignore the warnings.
|
||
|
||
-Wconversion isn't really intended for production use, only for shakedown
|
||
compiles after converting an old program to standard C.
|
||
|
||
|
||
? 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 ftp.gnu.org.
|
||
|
||
?? 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.
|
||
|
||
{PB} The 2.1 release of GNU libc aims to comply with the current versions of
|
||
all the relevant standards. The IPv6 support libraries for older Linux
|
||
systems used a different naming convention and so code written to work with
|
||
them may need to be modified. If the standards make incompatible changes in
|
||
the future then the libc may need to change again.
|
||
|
||
IPv6 will not work with a 2.0.x kernel. When kernel 2.2 is released it
|
||
should contain all the necessary support; until then you should use the
|
||
latest 2.1.x release you can find. As of 98/11/26 the currently recommended
|
||
kernel for IPv6 is 2.1.129.
|
||
|
||
Also, as of the 2.1 release the IPv6 API provided by GNU libc is not
|
||
100% complete. In particular the getipnodebyname and getipnodebyaddr
|
||
functions are not implemented.
|
||
|
||
??tzdb When I set the timezone by setting the TZ environment variable
|
||
to EST5EDT things go wrong since glibc computes the wrong time
|
||
from this information.
|
||
|
||
{UD} The problem is that people still use the braindamaged POSIX method to
|
||
select the timezone using the TZ environment variable with a format EST5EDT
|
||
or whatever. People, if you insist on using TZ instead of the timezone
|
||
database (see below), read the POSIX standard, the implemented behaviour is
|
||
correct! What you see is in fact the result of the decisions made while
|
||
POSIX.1 was created. We've only implemented the handling of TZ this way to
|
||
be POSIX compliant. It is not really meant to be used.
|
||
|
||
The alternative approach to handle timezones which is implemented is the
|
||
correct one to use: use the timezone database. This avoids all the problems
|
||
the POSIX method has plus it is much easier to use. Simply run the tzselect
|
||
shell script, answer the question and use the name printed in the end by
|
||
making a symlink /etc/localtime pointing to /usr/share/zoneinfo/NAME (NAME
|
||
is the returned value from tzselect). That's all. You never again have to
|
||
worry.
|
||
|
||
So, please avoid sending bug reports about time related problems if you use
|
||
the POSIX method and you have not verified something is really broken by
|
||
reading the POSIX standards.
|
||
|
||
?? What other sources of documentation about glibc are available?
|
||
|
||
{AJ} The FSF has a page about the GNU C library at
|
||
<http://www.gnu.org/software/libc/>. The problem data base of open and
|
||
solved bugs in GNU libc is available at
|
||
<http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl>. Eric Green has written
|
||
a HowTo for converting from Linux libc5 to glibc2. The HowTo is accessable
|
||
via the FSF page and at <http://www.imaxx.net/~thrytis/glibc>. Frodo
|
||
Looijaard describes a different way installing glibc2 as secondary libc at
|
||
<http://huizen.dds.nl/~frodol/glibc>.
|
||
|
||
Please note that this is not a complete list.
|
||
|
||
?? The timezone string for Sydney/Australia is wrong since even when
|
||
daylight saving time is in effect the timezone string is EST.
|
||
|
||
{UD} The problem for some timezones is that the local authorities decided
|
||
to use the term "summer time" instead of "daylight saving time". In this
|
||
case the abbreviation character `S' is the same as the standard one. So,
|
||
for Sydney we have
|
||
|
||
Eastern Standard Time = EST
|
||
Eastern Summer Time = EST
|
||
|
||
Great! To get this bug fixed convince the authorities to change the laws
|
||
and regulations of the country this effects. glibc behaves correctly.
|
||
|
||
??make I've build make 3.77 against glibc 2.1 and now make gets
|
||
segmentation faults.
|
||
|
||
{AJ} GNU make 3.77 has support for 64 bit filesystems which is slightly
|
||
broken (and one of the new features in the GNU C library 2.1 is 64 bit
|
||
filesystem support :-( ). To get a working make you can use either make
|
||
3.75 or patch 3.77. A working patch is available via RedHat's Rawhide server
|
||
(ftp://rawhide.redhat.com/SRPMS/SRPMS/make-3.77-*src.rpm).
|
||
|
||
|
||
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>
|
||
{TK} Thorsten Kukuk, <kukuk@vt.uni-paderborn.de>
|
||
{GK} Geoffrey Keating, <geoffk@ozemail.com.au>
|
||
{HJ} H.J. Lu, <hjl@gnu.org>
|
||
{CG} Cristian Gafton, <gafton@redhat.com>
|
||
|
||
Local Variables:
|
||
mode:outline
|
||
outline-regexp:"\\?"
|
||
fill-column:76
|
||
End:
|