1998-05-18 11:53:46 +02:00
|
|
|
Installing the GNU C Library
|
|
|
|
****************************
|
|
|
|
|
|
|
|
Before you do anything else, you should read the file `FAQ' found at
|
|
|
|
the top level of the source tree. This file answers common questions
|
|
|
|
and describes problems you may experience with compilation and
|
|
|
|
installation. It is updated more frequently than this manual.
|
|
|
|
|
1998-11-09 19:21:06 +01:00
|
|
|
Features can be added to GNU Libc via "add-on" bundles. These are
|
|
|
|
separate tarfiles which you unpack into the top level of the source
|
|
|
|
tree. Then you give `configure' the `--enable-add-ons' option to
|
|
|
|
activate them, and they will be compiled into the library. As of the
|
|
|
|
2.1 release, two important components of glibc are distributed as
|
|
|
|
"official" add-ons. Unless you are doing an unusual installation, you
|
|
|
|
should get them both.
|
|
|
|
|
|
|
|
Support for POSIX threads is maintained by someone else, so it's in a
|
|
|
|
separate package. It is only available for Linux systems, but this will
|
|
|
|
change in the future. Get it from the same place you got the main
|
|
|
|
bundle; the file is `glibc-linuxthreads-VERSION.tar.gz'. Support for
|
|
|
|
the `crypt' function is distributed separately because of United States
|
|
|
|
export restrictions. If you are outside the US or Canada, you must get
|
|
|
|
`crypt' support from a site outside the US, such as `ftp.ifi.uio.no'.
|
|
|
|
(Most non-US mirrors of `ftp.gnu.org' will have it too.) The file you
|
|
|
|
need is `glibc-crypt-VERSION.tar.gz'.
|
1998-11-05 00:04:21 +01:00
|
|
|
|
|
|
|
You will need recent versions of several GNU tools: definitely GCC
|
1998-11-05 14:03:24 +01:00
|
|
|
and GNU Make, and possibly others. *Note Tools for Compilation::,
|
1998-11-05 00:04:21 +01:00
|
|
|
below.
|
|
|
|
|
|
|
|
Configuring and compiling GNU Libc
|
|
|
|
==================================
|
|
|
|
|
1999-02-03 14:25:15 +01:00
|
|
|
GNU Libc can be compiled in the source directory but we'd advise to
|
|
|
|
build in a separate build directory. For example, if you have unpacked
|
1998-11-05 00:04:21 +01:00
|
|
|
the glibc sources in `/src/gnu/glibc-2.1.0', create a directory
|
|
|
|
`/src/gnu/glibc-build' to put the object files in.
|
|
|
|
|
|
|
|
From your object directory, run the shell script `configure' found
|
|
|
|
at the top level of the source tree. In the scenario above, you'd type
|
|
|
|
|
|
|
|
$ ../glibc-2.1.0/configure ARGS...
|
|
|
|
|
|
|
|
`configure' takes many options, but you can get away with knowing only
|
1998-11-09 19:21:06 +01:00
|
|
|
two: `--prefix' and `--enable-add-ons'. The `--prefix' option tells
|
|
|
|
configure where you want glibc installed. This defaults to
|
|
|
|
`/usr/local'. The `--enable-add-ons' option tells configure to use all
|
|
|
|
the add-on bundles it finds in the source directory. Since important
|
|
|
|
functionality is provided in add-ons, you should always give this
|
|
|
|
option.
|
1998-11-05 00:04:21 +01:00
|
|
|
|
|
|
|
It may also be useful to set the CC and CFLAGS variables in the
|
|
|
|
environment when running `configure'. CC selects the C compiler that
|
|
|
|
will be used, and CFLAGS sets optimization options for the compiler.
|
|
|
|
|
|
|
|
Here are all the useful options known by `configure':
|
|
|
|
|
|
|
|
`--prefix=DIRECTORY'
|
|
|
|
Install machine-independent data files in subdirectories of
|
|
|
|
`DIRECTORY'. The default is to install in `/usr/local'.
|
|
|
|
|
|
|
|
`--exec-prefix=DIRECTORY'
|
|
|
|
Install the library and other machine-dependent files in
|
|
|
|
subdirectories of `DIRECTORY'. The default is to the `--prefix'
|
|
|
|
directory if that option is given, or `/usr/local' otherwise.
|
|
|
|
|
|
|
|
`--with-headers=DIRECTORY'
|
|
|
|
Look for kernel header files in DIRECTORY, not `/usr/include'.
|
|
|
|
Glibc needs information from the kernel's private header files.
|
|
|
|
It will normally look in `/usr/include' for them, but if you give
|
|
|
|
this option, it will look in DIRECTORY instead.
|
|
|
|
|
|
|
|
This option is primarily of use on a system where the headers in
|
|
|
|
`/usr/include' come from an older version of glibc. Conflicts can
|
|
|
|
occasionally happen in this case. Note that Linux libc5 qualifies
|
|
|
|
as an older version of glibc. You can also use this option if you
|
|
|
|
want to compile glibc with a newer set of kernel headers than the
|
|
|
|
ones found in `/usr/include'.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
1998-11-05 00:04:21 +01:00
|
|
|
`--enable-add-ons[=LIST]'
|
|
|
|
Enable add-on packages in your source tree. If this option is
|
|
|
|
given with no list, it enables all the add-on packages it finds.
|
|
|
|
If you do not wish to use some add-on package that you have
|
|
|
|
present in your source tree, give this option a list of the
|
|
|
|
add-ons that you *do* want used, like this:
|
|
|
|
`--enable-add-ons=crypt,linuxthreads'
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
`--with-binutils=DIRECTORY'
|
|
|
|
Use the binutils (assembler and linker) in `DIRECTORY', not the
|
|
|
|
ones the C compiler would default to. You could use this option if
|
|
|
|
the default binutils on your system cannot deal with all the
|
|
|
|
constructs in the GNU C library. (`configure' will detect the
|
|
|
|
problem and suppress these constructs, so the library will still
|
|
|
|
be usable, but functionality may be lost--for example, you can not
|
|
|
|
build a shared libc with old binutils.)
|
|
|
|
|
|
|
|
`--without-fp'
|
|
|
|
Use this option if your computer lacks hardware floating-point
|
|
|
|
support and your operating system does not emulate an FPU.
|
|
|
|
|
1998-11-05 00:04:21 +01:00
|
|
|
`--disable-static'
|
|
|
|
Don't build static libraries. Static libraries aren't that useful
|
|
|
|
these days, but we recommend you build them in case you need them.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
`--disable-shared'
|
1998-11-05 00:04:21 +01:00
|
|
|
Don't build shared libraries even if we could. Not all systems
|
|
|
|
support shared libraries; you need ELF support and (currently) the
|
|
|
|
GNU linker.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
`--disable-profile'
|
1998-11-05 00:04:21 +01:00
|
|
|
Don't build libraries with profiling information. You may want to
|
|
|
|
use this option if you don't plan to do profiling.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
`--enable-omitfp'
|
1998-11-05 00:04:21 +01:00
|
|
|
Use maximum optimization for the normal (static and shared)
|
|
|
|
libraries, and compile separate static libraries with debugging
|
|
|
|
information and no optimisation. We recommend against this. The
|
|
|
|
extra optimization doesn't gain you much, it may provoke compiler
|
|
|
|
bugs, and you won't be able to trace bugs through the C library.
|
|
|
|
|
|
|
|
`--disable-versioning'
|
|
|
|
Don't compile the shared libraries with symbol version information.
|
|
|
|
Doing this will make the library that's built incompatible with old
|
|
|
|
binaries, so it's not recommended.
|
|
|
|
|
|
|
|
`--enable-static-nss'
|
|
|
|
Compile static versions of the NSS (Name Service Switch) libraries.
|
|
|
|
This is not recommended because it defeats the purpose of NSS; a
|
|
|
|
program linked statically with the NSS libraries cannot be
|
|
|
|
dynamically reconfigured to use a different name database.
|
|
|
|
|
|
|
|
`--build=BUILD-SYSTEM'
|
|
|
|
`--host=HOST-SYSTEM'
|
|
|
|
These options are for cross-compiling. If you give them both and
|
|
|
|
BUILD-SYSTEM is different from HOST-SYSTEM, `configure' will
|
|
|
|
prepare to cross-compile glibc from BUILD-SYSTEM to be used on
|
|
|
|
HOST-SYSTEM. You'll probably need the `--with-headers' option
|
|
|
|
too, and you may have to override CONFIGURE's selection of the
|
|
|
|
compiler and/or binutils.
|
|
|
|
|
1998-11-09 19:21:06 +01:00
|
|
|
If you give just `--host', configure will prepare for a native
|
|
|
|
compile but use what you say instead of guessing what your system
|
|
|
|
is. This is most useful to change the CPU submodel. For example,
|
|
|
|
if configure guesses your machine as `i586-pc-linux-gnu' but you
|
|
|
|
want to compile a library optimized for 386es, give
|
|
|
|
`--host=i386-pc-linux-gnu' or just `--host=i386-linux'. (A
|
|
|
|
library compiled for a Pentium (`i586') will still work on a 386,
|
|
|
|
but it may be slower.)
|
|
|
|
|
|
|
|
If you give just `--build', configure will get confused.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
To build the library and related programs, type `make'. This will
|
|
|
|
produce a lot of output, some of which may look like errors from `make'
|
1998-11-05 00:04:21 +01:00
|
|
|
but isn't. Look for error messages from `make' containing `***'.
|
1998-05-18 11:53:46 +02:00
|
|
|
Those indicate that something is really wrong.
|
|
|
|
|
1998-11-05 00:04:21 +01:00
|
|
|
The compilation process takes several hours even on fast hardware.
|
|
|
|
Expect at least two hours for the default configuration on i586 for
|
|
|
|
Linux. For Hurd times are much longer. Except for EGCS 1.1 (and later
|
|
|
|
versions of EGCS), all supported versions of GCC have a problem which
|
|
|
|
causes them to take several minutes to compile certain files in the
|
|
|
|
iconvdata directory. Do not panic if the compiler appears to hang.
|
|
|
|
|
|
|
|
If you want to run a parallel make, you can't just give `make' the
|
|
|
|
`-j' option, because it won't be passed down to the sub-makes.
|
|
|
|
Instead, edit the generated `Makefile' and uncomment the line
|
|
|
|
|
|
|
|
# PARALLELMFLAGS = -j 4
|
|
|
|
|
|
|
|
You can change the `4' to some other number as appropriate for your
|
|
|
|
system.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
To build and run some test programs which exercise some of the
|
1998-11-05 00:04:21 +01:00
|
|
|
library facilities, type `make check'. This should complete
|
|
|
|
successfully; if it doesn't, do not use the built library, and report a
|
|
|
|
bug. *Note Reporting Bugs::, for how to do that. Note that some of
|
|
|
|
the tests assume they are not being run by `root'. We recommend you
|
|
|
|
compile and test glibc as an unprivileged user.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
To format the `GNU C Library Reference Manual' for printing, type
|
1998-11-09 19:21:06 +01:00
|
|
|
`make dvi'. You need a working TeX installation to do this. The
|
|
|
|
distribution already includes the on-line formatted version of the
|
|
|
|
manual, as Info files. You can regenerate those with `make info', but
|
|
|
|
it shouldn't be necessary.
|
|
|
|
|
|
|
|
Installing the C Library
|
|
|
|
========================
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
To install the library and its header files, and the Info files of
|
|
|
|
the manual, type `make install'. This will build things if necessary,
|
1998-11-09 19:21:06 +01:00
|
|
|
before installing them. Don't rely on that; compile everything first.
|
|
|
|
If you are installing glibc as your primary C library, we recommend you
|
|
|
|
shut the system down to single-user mode first, and reboot afterward.
|
|
|
|
This minimizes the risk of breaking things when the library changes out
|
|
|
|
from underneath.
|
|
|
|
|
|
|
|
If you are upgrading from a previous installation of glibc 2.0 or
|
|
|
|
2.1, `make install' will do the entire job. If you're upgrading from
|
|
|
|
Linux libc5 or some other C library, you need to rename the old
|
|
|
|
`/usr/include' directory out of the way first, or you will end up with
|
|
|
|
a mixture of header files from both libraries, and you won't be able to
|
|
|
|
compile anything. You may also need to reconfigure GCC to work with
|
|
|
|
the new library. The easiest way to do that is to figure out the
|
|
|
|
compiler switches to make it work again
|
|
|
|
(`-Wl,-dynamic-linker=/lib/ld-linux.so.2' should work on Linux systems)
|
|
|
|
and use them to recompile gcc. You can also edit the specs file
|
|
|
|
(`/usr/lib/gcc-lib/TARGET/VERSION/specs'), but that is a bit of a black
|
|
|
|
art.
|
|
|
|
|
|
|
|
You can install glibc somewhere other than where you configured it
|
|
|
|
to go by setting the `install_root' variable on the command line for
|
|
|
|
`make install'. The value of this variable is prepended to all the
|
|
|
|
paths for installation. This is useful when setting up a chroot
|
|
|
|
environment or preparing a binary distribution.
|
|
|
|
|
|
|
|
Glibc 2.1 includes two daemons, `nscd' and `utmpd', which you may or
|
|
|
|
may not want to run. `nscd' caches name service lookups; it can
|
|
|
|
dramatically improve performance with NIS+, and may help with DNS as
|
|
|
|
well. `utmpd' allows programs that use the old format for the `utmp'
|
|
|
|
file to coexist with new programs. For more information see the files
|
|
|
|
`nscd/README' and `login/README.utmpd'.
|
|
|
|
|
|
|
|
One auxiliary program, `/usr/libexec/pt_chown', is installed setuid
|
|
|
|
`root'. This program is invoked by the `grantpt' function; it sets the
|
|
|
|
permissions on a pseudoterminal so it can be used by the calling
|
|
|
|
process. This means programs like `xterm' and `screen' do not have to
|
|
|
|
be setuid to get a pty. (There may be other reasons why they need
|
1999-02-03 14:25:15 +01:00
|
|
|
privileges.) If you are using a 2.1 or newer Linux kernel with the
|
|
|
|
`devptsfs' or `devfs' filesystems providing pty slaves, you don't need
|
|
|
|
this program; otherwise you do. The source for `pt_chown' is in
|
1998-11-09 19:21:06 +01:00
|
|
|
`login/programs/pt_chown.c'.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
1998-11-05 00:04:21 +01:00
|
|
|
Recommended Tools for Compilation
|
|
|
|
=================================
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
We recommend installing the following GNU tools before attempting to
|
|
|
|
build the GNU C library:
|
|
|
|
|
|
|
|
* GNU `make' 3.75
|
|
|
|
|
|
|
|
You need the latest version of GNU `make'. Modifying the GNU C
|
|
|
|
Library to work with other `make' programs would be so hard that we
|
|
|
|
recommend you port GNU `make' instead. *Really.* We recommend
|
1998-11-05 00:04:21 +01:00
|
|
|
version GNU `make' version 3.75 or 3.77. All earlier versions
|
|
|
|
have severe bugs or lack features. Version 3.76 is known to have
|
|
|
|
bugs which only show up in big projects like GNU `libc'. Version
|
|
|
|
3.76.1 seems OK but some people have reported problems.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
1998-11-30 17:42:19 +01:00
|
|
|
* EGCS 1.1.1, 1.1 or 1.0.3
|
1998-05-18 11:53:46 +02:00
|
|
|
|
1998-11-05 00:04:21 +01:00
|
|
|
The GNU C library can only be compiled with the GNU C compiler
|
|
|
|
family. We recommend EGCS 1.0.3 or higher. GCC 2.8.1 and older
|
|
|
|
versions of EGCS may have problems, particularly on non-Intel
|
|
|
|
architectures. GCC 2.7.x has catastrophic bugs and cannot be used
|
1998-11-09 19:21:06 +01:00
|
|
|
at all. (You can use GCC 2.7.x to compile programs that use GNU
|
|
|
|
libc, but you may have problems, particularly with the math
|
|
|
|
functions.)
|
1998-05-18 11:53:46 +02:00
|
|
|
|
1998-11-30 17:42:19 +01:00
|
|
|
On Alpha machines you need at least EGCS 1.1.1. Earlier versions
|
|
|
|
don't work reliably.
|
|
|
|
|
|
|
|
For PPC you might need some patches even on top of the last EGCS
|
|
|
|
version. See the FAQ.
|
|
|
|
|
|
|
|
* GNU `binutils' 2.9.1, or 2.9.1.0.16
|
1998-05-18 11:53:46 +02:00
|
|
|
|
1998-11-05 00:04:21 +01:00
|
|
|
You must use GNU binutils (as and ld) if you want to build a shared
|
|
|
|
library. Even if you don't, we recommend you use them anyway. No
|
|
|
|
one has tested compilation with non-GNU binutils in a long time.
|
|
|
|
|
|
|
|
The quality of binutils releases has varied a bit recently. The
|
|
|
|
bugs are in obscure features, but glibc uses quite a few of those.
|
1998-11-30 17:42:19 +01:00
|
|
|
2.9.1 and 2.9.1.0.16 are known to work. Versions after 2.8.1.0.23
|
|
|
|
may or may not work. Older versions definitely don't. 2.9.1.0.16
|
|
|
|
is required on some platforms, like PPC and Arm.
|
|
|
|
|
|
|
|
For PPC you might need some patches even on top of the last
|
|
|
|
binutils version. See the FAQ.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
* GNU `texinfo' 3.11
|
|
|
|
|
|
|
|
To correctly translate and install the Texinfo documentation you
|
|
|
|
need this version of the `texinfo' package. Earlier versions do
|
|
|
|
not understand all the tags used in the document, and the
|
1998-11-09 19:21:06 +01:00
|
|
|
installation mechanism for the info files is not present or works
|
1998-05-18 11:53:46 +02:00
|
|
|
differently.
|
|
|
|
|
1998-11-05 00:04:21 +01:00
|
|
|
* GNU `awk' 3.0, or some other POSIX awk
|
|
|
|
|
|
|
|
Awk is used in several places to generate files. The scripts
|
1998-11-09 19:21:06 +01:00
|
|
|
should work with any POSIX-compliant awk implementation; `gawk'
|
1998-11-05 00:04:21 +01:00
|
|
|
3.0 and `mawk' 1.3 are known to work.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
1998-11-05 00:04:21 +01:00
|
|
|
* Perl 5
|
|
|
|
|
|
|
|
Perl is not required, but it is used if present to test the
|
|
|
|
installation. We may decide to use it elsewhere in the future.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
If you change any of the `configure.in' files you will also need
|
|
|
|
|
|
|
|
* GNU `autoconf' 2.12
|
|
|
|
|
|
|
|
and if you change any of the message translation files you will need
|
|
|
|
|
1998-11-05 00:04:21 +01:00
|
|
|
* GNU `gettext' 0.10.35 or later
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
You may also need these packages if you upgrade your source tree using
|
|
|
|
patches, although we try to avoid this.
|
|
|
|
|
|
|
|
Supported Configurations
|
|
|
|
========================
|
|
|
|
|
|
|
|
The GNU C Library currently supports configurations that match the
|
|
|
|
following patterns:
|
|
|
|
|
1998-11-05 00:04:21 +01:00
|
|
|
alpha-*-linux
|
1998-11-30 17:42:19 +01:00
|
|
|
arm-*-linux
|
1998-11-05 00:04:21 +01:00
|
|
|
arm-*-linuxaout
|
|
|
|
arm-*-none
|
|
|
|
iX86-*-gnu
|
|
|
|
iX86-*-linux
|
|
|
|
m68k-*-linux
|
|
|
|
powerpc-*-linux
|
|
|
|
sparc-*-linux
|
|
|
|
sparc64-*-linux
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
Former releases of this library (version 1.09.1 and perhaps earlier
|
|
|
|
versions) used to run on the following configurations:
|
|
|
|
|
|
|
|
alpha-dec-osf1
|
1998-11-05 00:04:21 +01:00
|
|
|
alpha-*-linuxecoff
|
|
|
|
iX86-*-bsd4.3
|
|
|
|
iX86-*-isc2.2
|
|
|
|
iX86-*-isc3.N
|
|
|
|
iX86-*-sco3.2
|
|
|
|
iX86-*-sco3.2v4
|
|
|
|
iX86-*-sysv
|
|
|
|
iX86-*-sysv4
|
1998-05-18 11:53:46 +02:00
|
|
|
iX86-force_cpu386-none
|
|
|
|
iX86-sequent-bsd
|
|
|
|
i960-nindy960-none
|
|
|
|
m68k-hp-bsd4.3
|
|
|
|
m68k-mvme135-none
|
|
|
|
m68k-mvme136-none
|
|
|
|
m68k-sony-newsos3
|
|
|
|
m68k-sony-newsos4
|
|
|
|
m68k-sun-sunos4.N
|
|
|
|
mips-dec-ultrix4.N
|
|
|
|
mips-sgi-irix4.N
|
|
|
|
sparc-sun-solaris2.N
|
|
|
|
sparc-sun-sunos4.N
|
|
|
|
|
|
|
|
Since no one has volunteered to test and fix these configurations,
|
|
|
|
they are not supported at the moment. They probably don't compile;
|
|
|
|
they definitely don't work anymore. Porting the library is not hard.
|
|
|
|
If you are interested in doing a port, please contact the glibc
|
|
|
|
maintainers by sending electronic mail to <bug-glibc@gnu.org>.
|
|
|
|
|
|
|
|
Each case of `iX86' can be `i386', `i486', `i586', or `i686'. All
|
|
|
|
of those configurations produce a library that can run on any of these
|
|
|
|
processors. The library will be optimized for the specified processor,
|
1998-11-09 19:21:06 +01:00
|
|
|
but will not use instructions not available on all of them. If you
|
|
|
|
want the library to use instructions only available on newer
|
|
|
|
processors, give GCC the appropriate `-m' switches via CFLAGS.
|
|
|
|
|
|
|
|
Specific advice for Linux systems
|
|
|
|
=================================
|
|
|
|
|
|
|
|
If you are installing GNU libc on a Linux system, you need to have
|
|
|
|
the header files from a development kernel around for reference. You
|
|
|
|
do not need to use the development kernel, just have its headers where
|
|
|
|
glibc can get at them. The easiest way to do this is to unpack a
|
|
|
|
development kernel in a directory such as `/usr/src/linux-dev'. In that
|
|
|
|
directory, run `make config' and accept all the defaults. Then
|
|
|
|
configure glibc with the option
|
|
|
|
`--with-headers=/usr/src/linux-dev/include'. Use the latest
|
|
|
|
development kernel you can get your hands on.
|
|
|
|
|
|
|
|
An alternate tactic is to unpack the development kernel and run
|
|
|
|
`make config' as above. Then rename or delete `/usr/include', create a
|
|
|
|
new `/usr/include', and make the usual symbolic links of
|
|
|
|
`/usr/include/linux' and `/usr/include/asm' into the development kernel
|
|
|
|
sources. You can then configure glibc with no special options. This
|
|
|
|
tactic is recommended if you are upgrading from libc5, since you need
|
|
|
|
to get rid of the old header files anyway.
|
|
|
|
|
|
|
|
Note that `/usr/include/net' and `/usr/include/scsi' should *not* be
|
|
|
|
symlinks into the kernel sources. GNU libc provides its own versions
|
|
|
|
of these files.
|
|
|
|
|
|
|
|
Linux expects some components of the libc installation to be in
|
|
|
|
`/lib' and some in `/usr/lib'. This is handled automatically if you
|
|
|
|
configure glibc with `--prefix=/usr'. If you set some other prefix or
|
|
|
|
allow it to default to `/usr/local', then all the components are
|
|
|
|
installed there.
|
|
|
|
|
|
|
|
If you are upgrading from libc5, you need to recompile every shared
|
|
|
|
library on your system against the new library for the sake of new code,
|
|
|
|
but keep the old libraries around for old binaries to use. This is
|
|
|
|
complicated and difficult. Consult the Glibc2 HOWTO at
|
|
|
|
`http://www.imaxx.net/~thrytis/glibc' for details.
|
|
|
|
|
|
|
|
You cannot use `nscd' with 2.0 kernels, due to bugs in the
|
|
|
|
kernel-side thread support. `nscd' happens to hit these bugs
|
|
|
|
particularly hard, but you might have problems with any threaded
|
|
|
|
program.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
Reporting Bugs
|
|
|
|
==============
|
|
|
|
|
|
|
|
There are probably bugs in the GNU C library. There are certainly
|
|
|
|
errors and omissions in this manual. If you report them, they will get
|
|
|
|
fixed. If you don't, no one will ever know about them and they will
|
|
|
|
remain unfixed for all eternity, if not longer.
|
|
|
|
|
|
|
|
To report a bug, first you must find it. Hopefully, this will be the
|
|
|
|
hard part. Once you've found a bug, make sure it's really a bug. A
|
|
|
|
good way to do this is to see if the GNU C library behaves the same way
|
|
|
|
some other C library does. If so, probably you are wrong and the
|
|
|
|
libraries are right (but not necessarily). If not, one of the libraries
|
1998-11-09 19:21:06 +01:00
|
|
|
is probably wrong. It might not be the GNU library. Many historical
|
|
|
|
Unix C libraries permit things that we don't, such as closing a file
|
|
|
|
twice.
|
|
|
|
|
|
|
|
If you think you have found some way in which the GNU C library does
|
|
|
|
not conform to the ISO and POSIX standards (*note Standards and
|
|
|
|
Portability::.), that is definitely a bug. Report it!
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
Once you're sure you've found a bug, try to narrow it down to the
|
|
|
|
smallest test case that reproduces the problem. In the case of a C
|
|
|
|
library, you really only need to narrow it down to one library function
|
|
|
|
call, if possible. This should not be too difficult.
|
|
|
|
|
|
|
|
The final step when you have a simple test case is to report the bug.
|
1998-11-09 19:21:06 +01:00
|
|
|
Do this using the `glibcbug' script. It is installed with libc, or if
|
|
|
|
you haven't installed it, will be in your build directory. Send your
|
|
|
|
test case, the results you got, the results you expected, and what you
|
|
|
|
think the problem might be (if you've thought of anything). `glibcbug'
|
|
|
|
will insert the configuration information we need to see, and ship the
|
|
|
|
report off to <bug-glibc@gnu.org>. Don't send a message there
|
|
|
|
directly; it is fed to a program that expects mail to be formatted in a
|
|
|
|
particular way. Use the script.
|
1998-05-18 11:53:46 +02:00
|
|
|
|
|
|
|
If you are not sure how a function should behave, and this manual
|
|
|
|
doesn't tell you, that's a bug in the manual. Report that too! If the
|
|
|
|
function's behavior disagrees with the manual, then either the library
|
|
|
|
or the manual has a bug, so report the disagreement. If you find any
|
|
|
|
errors or omissions in this manual, please report them to the Internet
|
|
|
|
address <bug-glibc-manual@gnu.org>. If you refer to specific sections
|
|
|
|
when reporting on the manual, please include the section names for
|
|
|
|
easier identification.
|
1995-02-18 02:27:10 +01:00
|
|
|
|