path: root/FAQ.in

	    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