mirror of
https://sourceware.org/git/glibc.git
synced 2024-11-17 18:40:14 +00:00
582 lines
26 KiB
Plaintext
582 lines
26 KiB
Plaintext
@c This is for making the `INSTALL' file for the distribution.
|
|
@c Makeinfo ignores it when processing the file from the include.
|
|
@setfilename INSTALL
|
|
|
|
@node Installation, Maintenance, Library Summary, Top
|
|
@c %MENU% How to install the GNU C library
|
|
@appendix Installing the GNU C Library
|
|
|
|
Before you do anything else, you should read the file @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.
|
|
|
|
Features can be added to GNU Libc via @dfn{add-on} bundles. These are
|
|
separate tarfiles which you unpack into the top level of the source
|
|
tree. Then you give @code{configure} the @samp{--enable-add-ons} option
|
|
to activate them, and they will be compiled into the library. As of the
|
|
2.2 release, one important component of glibc is distributed as
|
|
``official'' add-ons: the linuxthreads add-on. Unless you are doing an
|
|
unusual installation, you should get this.
|
|
|
|
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 @file{glibc-linuxthreads-@var{VERSION}.tar.gz}.
|
|
|
|
You will need recent versions of several GNU tools: definitely GCC and
|
|
GNU Make, and possibly others. @xref{Tools for Compilation}, below.
|
|
|
|
@menu
|
|
* Configuring and compiling:: How to compile and test GNU libc.
|
|
* Running make install:: How to install it once you've got it compiled.
|
|
* Tools for Compilation:: You'll need these first.
|
|
* Supported Configurations:: What it runs on, what it doesn't.
|
|
* Linux:: Specific advice for Linux systems.
|
|
* Reporting Bugs:: So they'll get fixed.
|
|
@end menu
|
|
|
|
@node Configuring and compiling
|
|
@appendixsec Configuring and compiling GNU Libc
|
|
@cindex configuring
|
|
@cindex compiling
|
|
|
|
GNU libc can be compiled in the source directory, but we strongly advise to
|
|
build it in a separate build directory. For example, if you have unpacked
|
|
the glibc sources in @file{/src/gnu/glibc-2.2.0}, create a directory
|
|
@file{/src/gnu/glibc-build} to put the object files in. This allows
|
|
removing the whole build directory in case an error occurs, which is the
|
|
safest way to get a fresh start and should always be done.
|
|
|
|
From your object directory, run the shell script @file{configure} found
|
|
at the top level of the source tree. In the scenario above, you'd type
|
|
|
|
@smallexample
|
|
$ ../glibc-2.2.0/configure @var{args...}
|
|
@end smallexample
|
|
|
|
Please note that even if you're building in a separate build directory,
|
|
the compilation needs to modify a few files in the source
|
|
directory, especially some files in the manual subdirectory.
|
|
|
|
@noindent
|
|
@code{configure} takes many options, but you can get away with knowing
|
|
only two: @samp{--prefix} and @samp{--enable-add-ons}. The
|
|
@code{--prefix} option tells configure where you want glibc installed.
|
|
This defaults to @file{/usr/local}. The @samp{--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 specify this option.
|
|
|
|
It may also be useful to set the @var{CC} and @var{CFLAGS} variables in
|
|
the environment when running @code{configure}. @var{CC} selects the C
|
|
compiler that will be used, and @var{CFLAGS} sets optimization options
|
|
for the compiler.
|
|
|
|
The following list describes all of the available options for @code{configure}:
|
|
|
|
@table @samp
|
|
@item --prefix=@var{directory}
|
|
Install machine-independent data files in subdirectories of
|
|
@file{@var{directory}}. The default is to install in @file{/usr/local}.
|
|
|
|
@item --exec-prefix=@var{directory}
|
|
Install the library and other machine-dependent files in subdirectories
|
|
of @file{@var{directory}}. The default is to the @samp{--prefix}
|
|
directory if that option is specified, or @file{/usr/local} otherwise.
|
|
|
|
@item --with-headers=@var{directory}
|
|
Look for kernel header files in @var{directory}, not
|
|
@file{/usr/include}. Glibc needs information from the kernel's private
|
|
header files. It will normally look in @file{/usr/include} for them,
|
|
but if you specify this option, it will look in @var{DIRECTORY} instead.
|
|
|
|
This option is primarily of use on a system where the headers in
|
|
@file{/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
|
|
@file{/usr/include}.
|
|
|
|
@item --enable-add-ons[=@var{list}]
|
|
Enable add-on packages in your source tree. If this option is specified
|
|
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 @emph{do} want
|
|
used, like this: @samp{--enable-add-ons=linuxthreads}
|
|
|
|
@item --with-binutils=@var{directory}
|
|
Use the binutils (assembler and linker) in @file{@var{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. In that case, @code{configure} will detect the problem and
|
|
suppress these constructs, so that the library will still be usable, but
|
|
functionality may be lost---for example, you can't build a shared libc
|
|
with old binutils.
|
|
|
|
@item --without-fp
|
|
Use this option if your computer lacks hardware floating-point support
|
|
and your operating system does not emulate an FPU.
|
|
|
|
@c disable static doesn't work currently
|
|
@c @item --disable-static
|
|
@c Don't build static libraries. Static libraries aren't that useful these
|
|
@c days, but we recommend you build them in case you need them.
|
|
|
|
@item --disable-shared
|
|
Don't build shared libraries even if it is possible. Not all systems support
|
|
shared libraries; you need ELF support and (currently) the GNU linker.
|
|
|
|
@item --disable-profile
|
|
Don't build libraries with profiling information. You may want to use
|
|
this option if you don't plan to do profiling.
|
|
|
|
@item --enable-omitfp
|
|
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.
|
|
|
|
@item --disable-versioning
|
|
Don't compile the shared libraries with symbol version information.
|
|
Doing this will make the resulting library incompatible with old
|
|
binaries, so it's not recommended.
|
|
|
|
@item --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.
|
|
|
|
@item --build=@var{build-system}
|
|
@itemx --host=@var{host-system}
|
|
These options are for cross-compiling. If you specify both options and
|
|
@var{build-system} is different from @var{host-system}, @code{configure}
|
|
will prepare to cross-compile glibc from @var{build-system} to be used
|
|
on @var{host-system}. You'll probably need the @samp{--with-headers}
|
|
option too, and you may have to override @var{configure}'s selection of
|
|
the compiler and/or binutils.
|
|
|
|
If you only specify @samp{--host}, configure will prepare for a native
|
|
compile but use what you specify instead of guessing what your system is.
|
|
This is most useful to change the CPU submodel. For example, if
|
|
configure guesses your machine as @code{i586-pc-linux-gnu} but you want
|
|
to compile a library for 386es, give @samp{--host=i386-pc-linux-gnu} or
|
|
just @samp{--host=i386-linux} and add the appropriate compiler flags
|
|
(@samp{-mcpu=i386} will do the trick) to @var{CFLAGS}.
|
|
|
|
If you specify just @samp{--build}, configure will get confused.
|
|
@end table
|
|
|
|
To build the library and related programs, type @code{make}. This will
|
|
produce a lot of output, some of which may look like errors from
|
|
@code{make} but isn't. Look for error messages from @code{make}
|
|
containing @samp{***}. Those indicate that something is really wrong.
|
|
|
|
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 GCC
|
|
2.95 (and later versions of GCC), 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 @code{make} the
|
|
@samp{-j} option, because it won't be passed down to the sub-makes.
|
|
Instead, edit the generated @file{Makefile} and uncomment the line
|
|
|
|
@smallexample
|
|
# PARALLELMFLAGS = -j 4
|
|
@end smallexample
|
|
|
|
@noindent
|
|
You can change the @samp{4} to some other number as appropriate for
|
|
your system. Instead of changing the @file{Makefile}, you could give
|
|
this option directly to @code{make} and call it as, for example,
|
|
@code{make PARALLELMFLAGS=-j4}. If you're building in the source
|
|
directory, you must use the latter approach since in this case no
|
|
new @file{Makefile} is generated for you to change.
|
|
|
|
To build and run test programs which exercise some of the library
|
|
facilities, type @code{make check}. If it does not complete
|
|
successfully, do not use the built library, and report a bug after
|
|
verifying that the problem is not already known. @xref{Reporting Bugs},
|
|
for instructions on reporting bugs. Note that some of the tests assume
|
|
they are not being run by @code{root}. We recommend you compile and
|
|
test glibc as an unprivileged user.
|
|
|
|
To format the @cite{GNU C Library Reference Manual} for printing, type
|
|
@w{@code{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 @w{@code{make
|
|
info}}, but it shouldn't be necessary.
|
|
|
|
The library has a number of special-purpose configuration parameters
|
|
which you can find in @file{Makeconfig}. These can be overwritten with
|
|
the file @file{configparms}. To change them, create a
|
|
@file{configparms} in your build directory and add values as appropriate
|
|
for your system. The file is included and parsed by @code{make} and has
|
|
to follow the conventions for makefiles.
|
|
|
|
It is easy to configure the GNU C library for cross-compilation by
|
|
setting a few variables in @file{configparms}. Set @code{CC} to the
|
|
cross-compiler for the target you configured the library for; it is
|
|
important to use this same @code{CC} value when running
|
|
@code{configure}, like this: @samp{CC=@var{target}-gcc configure
|
|
@var{target}}. Set @code{BUILD_CC} to the compiler to use for for
|
|
programs run on the build system as part of compiling the library. You
|
|
may need to set @code{AR} and @code{RANLIB} to cross-compiling versions
|
|
of @code{ar} and @code{ranlib} if the native tools are not configured to
|
|
work with object files for the target you configured for.
|
|
|
|
|
|
@node Running make install
|
|
@appendixsec Installing the C Library
|
|
@cindex installing
|
|
|
|
To install the library and its header files, and the Info files of the
|
|
manual, type @code{make install}. This will build things if necessary,
|
|
before installing them. However, you should still compile everything first.
|
|
If you are installing glibc as your primary C library, we recommend that 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're upgrading from Linux libc5 or some other C library, you need to
|
|
replace the @file{/usr/include} with a fresh directory before installing it.
|
|
The new @file{/usr/include} should contain the Linux headers, but nothing else.
|
|
|
|
You must first build the library (@samp{make}), optionally check it
|
|
(@samp{make check}), switch the include directories and then install
|
|
(@samp{make install}). The steps must be done in this order. Not moving
|
|
the directory before install will result in an unusable mixture of header
|
|
files from both libraries, but configuring, building, and checking the
|
|
library requires the ability to compile and run programs against the old
|
|
library.
|
|
|
|
If you are upgrading from a previous installation of glibc 2.0 or 2.1,
|
|
@samp{make install} will do the entire job. You do not need to remove
|
|
the old includes -- if you want to do so anyway you must then follow the
|
|
order given above.
|
|
|
|
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 (@samp{-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 (@file{/usr/lib/gcc-lib/@var{TARGET}/@var{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 @code{install_root} variable on the command line for
|
|
@samp{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. The directory should be
|
|
specified with an absolute file name.
|
|
|
|
Glibc 2.2 includes a daemon called @code{nscd}, which you
|
|
may or may not want to run. @code{nscd} caches name service lookups; it
|
|
can dramatically improve performance with NIS+, and may help with DNS as
|
|
well.
|
|
|
|
One auxiliary program, @file{/usr/libexec/pt_chown}, is installed setuid
|
|
@code{root}. This program is invoked by the @code{grantpt} function; it
|
|
sets the permissions on a pseudoterminal so it can be used by the
|
|
calling process. This means programs like @code{xterm} and
|
|
@code{screen} do not have to be setuid to get a pty. (There may be
|
|
other reasons why they need privileges.) If you are using a 2.1 or
|
|
newer Linux kernel with the @code{devptsfs} or @code{devfs} filesystems
|
|
providing pty slaves, you don't need this program; otherwise you do.
|
|
The source for @file{pt_chown} is in @file{login/programs/pt_chown.c}.
|
|
|
|
After installation you might want to configure the timezone and locale
|
|
installation of your system. The GNU C library comes with a locale
|
|
database which gets configured with @code{localedef}. For example, to
|
|
set up a German locale with name @code{de_DE}, simply issue the command
|
|
@samp{localedef -i de_DE -f ISO-8859-1 de_DE}. To configure all locales
|
|
that are supported by glibc, you can issue from your build directory the
|
|
command @samp{make localedata/install-locales}.
|
|
|
|
To configure the locally used timezone, you can either set the @code{TZ}
|
|
environment variable. The script @code{tzselect} helps you to select
|
|
the right value. As an example for Germany, tzselect would tell you to
|
|
use @samp{TZ='Europe/Berlin'}. For a system wide installation (the
|
|
given paths are for an installation with @samp{--prefix=/usr}), link the
|
|
timezone file which is in @file{/usr/share/zoneinfo} to the file
|
|
@file{/etc/localtime}. For Germany, you might execute @samp{ln -s
|
|
/usr/share/zoneinfo/Europe/Berlin /etc/localtime}.
|
|
|
|
@node Tools for Compilation
|
|
@appendixsec Recommended Tools for Compilation
|
|
@cindex installation tools
|
|
@cindex tools, for installing library
|
|
|
|
We recommend installing the following GNU tools before attempting to
|
|
build the GNU C library:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
GNU @code{make} 3.79 or newer
|
|
|
|
You need the latest version of GNU @code{make}. Modifying the GNU C
|
|
Library to work with other @code{make} programs would be so difficult that we
|
|
recommend you port GNU @code{make} instead. @strong{Really.} We
|
|
recommend version GNU @code{make} version 3.79. All earlier
|
|
versions have severe bugs or lack features.
|
|
|
|
@item
|
|
EGCS 1.1.1, 1.1 or 1.0.3, or GCC 2.8.1, 2.95 or newer
|
|
|
|
The GNU C library can only be compiled with the GNU C compiler family.
|
|
As of the 2.1 release, EGCS 1.0.3 or higher is required. GCC 2.8.1 can
|
|
also be used (but see the FAQ for reasons why you might not want to).
|
|
Earlier versions simply are too buggy. As of this writing, GCC 2.95.2
|
|
is the compiler we advise to use.
|
|
|
|
You can use whatever compiler you like to compile programs that use GNU
|
|
libc, but be aware that both GCC 2.7 and 2.8 have bugs in their
|
|
floating-point support that may be triggered by the math library.
|
|
|
|
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.
|
|
|
|
@item
|
|
GNU @code{binutils} 2.9.1, 2.9.1.0.16, or later 2.9.1.0.x release
|
|
|
|
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. 2.9.1,
|
|
2.9.1.0.16, and later 2.9.1.0.x releases 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 or higher 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.
|
|
|
|
@item
|
|
GNU @code{texinfo} 3.12f
|
|
|
|
To correctly translate and install the Texinfo documentation you need
|
|
this version of the @code{texinfo} package. Earlier versions do not
|
|
understand all the tags used in the document, and the installation
|
|
mechanism for the info files is not present or works differently.
|
|
|
|
@item
|
|
GNU @code{awk} 3.0, or some other POSIX awk
|
|
|
|
Awk is used in several places to generate files. The scripts should
|
|
work with any POSIX-compliant awk implementation; @code{gawk} 3.0 and
|
|
@code{mawk} 1.3 are known to work.
|
|
|
|
@item
|
|
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.
|
|
|
|
@item
|
|
GNU @code{sed} 3.02 or newer
|
|
|
|
Sed is used in several places to generate files. Most scripts work with
|
|
any version of @code{sed}. The known exception is the script
|
|
@code{po2test.sed} in the @code{intl} subdirectory which is used to
|
|
generate @code{msgs.h} for the testsuite. This script works correctly
|
|
only with GNU @code{sed} 3.02. If you like to run the testsuite, you
|
|
should definitly upgrade @code{sed}.
|
|
|
|
@end itemize
|
|
|
|
@noindent
|
|
If you change any of the @file{configure.in} files you will also need
|
|
|
|
@itemize @bullet
|
|
@item
|
|
GNU @code{autoconf} 2.12 or higher
|
|
@end itemize
|
|
|
|
@noindent
|
|
and if you change any of the message translation files you will need
|
|
|
|
@itemize @bullet
|
|
@item
|
|
GNU @code{gettext} 0.10.35 or later (version 0.10.35 is a alpha release
|
|
and available via ftp from alpha.gnu.org/gnu)
|
|
@end itemize
|
|
|
|
@noindent
|
|
You may also need these packages if you upgrade your source tree using
|
|
patches, although we try to avoid this.
|
|
|
|
@node Supported Configurations
|
|
@appendixsec Supported Configurations
|
|
@cindex configurations, all supported
|
|
|
|
The GNU C Library currently supports configurations that match the
|
|
following patterns:
|
|
|
|
@smallexample
|
|
alpha@var{*}-@var{*}-linux
|
|
arm-@var{*}-linux
|
|
arm-@var{*}-linuxaout
|
|
arm-@var{*}-none
|
|
i@var{x}86-@var{*}-gnu
|
|
i@var{x}86-@var{*}-linux
|
|
ia64-@var{*}-linux
|
|
m68k-@var{*}-linux
|
|
mips@var{*}-@var{*}-linux
|
|
powerpc-@var{*}-linux
|
|
s390-@var{*}-linux
|
|
sparc-@var{*}-linux
|
|
sparc64-@var{*}-linux
|
|
@end smallexample
|
|
|
|
Former releases of this library (version 1.09.1 and perhaps earlier
|
|
versions) used to run on the following configurations:
|
|
|
|
@smallexample
|
|
alpha-dec-osf1
|
|
alpha-@var{*}-linuxecoff
|
|
i@var{x}86-@var{*}-bsd4.3
|
|
i@var{x}86-@var{*}-isc2.2
|
|
i@var{x}86-@var{*}-isc3.@var{n}
|
|
i@var{x}86-@var{*}-sco3.2
|
|
i@var{x}86-@var{*}-sco3.2v4
|
|
i@var{x}86-@var{*}-sysv
|
|
i@var{x}86-@var{*}-sysv4
|
|
i@var{x}86-force_cpu386-none
|
|
i@var{x}86-sequent-bsd
|
|
i960-nindy960-none
|
|
m68k-hp-bsd4.3
|
|
m68k-mvme135-none
|
|
m68k-mvme136-none
|
|
m68k-sony-newsos3
|
|
m68k-sony-newsos4
|
|
m68k-sun-sunos4.@var{n}
|
|
mips-dec-ultrix4.@var{n}
|
|
mips-sgi-irix4.@var{n}
|
|
sparc-sun-solaris2.@var{n}
|
|
sparc-sun-sunos4.@var{n}
|
|
@end smallexample
|
|
|
|
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 @email{bug-glibc@@gnu.org}.
|
|
|
|
Valid cases of @samp{i@var{x}86} include @samp{i386}, @samp{i486},
|
|
@samp{i586}, and @samp{i686}. All of those configurations produce a
|
|
library that can run on this processor and newer processors. The GCC
|
|
compiler by default generates code that's optimized for the machine it's
|
|
configured for and will use the instructions available on that machine.
|
|
For example if your GCC is configured for @samp{i686}, gcc will optimize
|
|
for @samp{i686} and might issue some @samp{i686} specific instructions.
|
|
To generate code for other models, you have to configure for that model
|
|
and give GCC the appropriate @samp{-march=} and @samp{-mcpu=} compiler
|
|
switches via @var{CFLAGS}.
|
|
|
|
@node Linux
|
|
@appendixsec Specific advice for Linux systems
|
|
@cindex upgrading from libc5
|
|
@cindex kernel header files
|
|
|
|
If you are installing GNU libc on a Linux system, you need to have
|
|
the header files from a 2.2 kernel around for reference. You do not
|
|
need to use the 2.2 kernel, just have its headers where glibc can access
|
|
at them. The easiest way to do this is to unpack it in a directory
|
|
such as @file{/usr/src/linux-2.2.1}. In that directory, run
|
|
@samp{make config} and accept all the defaults. Then run @samp{make
|
|
include/linux/version.h}. Finally, configure glibc with the option
|
|
@samp{--with-headers=/usr/src/linux-2.2.1/include}. Use the most recent
|
|
kernel you can get your hands on.
|
|
|
|
An alternate tactic is to unpack the 2.2 kernel and run @samp{make
|
|
config} as above. Then rename or delete @file{/usr/include}, create
|
|
a new @file{/usr/include}, and make the usual symbolic links of
|
|
@file{/usr/include/linux} and @file{/usr/include/asm} into the 2.2
|
|
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 @file{/usr/include/net} and @file{/usr/include/scsi} should
|
|
@strong{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
|
|
@file{/lib} and some in @file{/usr/lib}. This is handled automatically
|
|
if you configure glibc with @samp{--prefix=/usr}. If you set some other
|
|
prefix or allow it to default to @file{/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
|
|
@url{http://www.imaxx.net/~thrytis/glibc} for details.
|
|
|
|
You cannot use @code{nscd} with 2.0 kernels, due to bugs in the
|
|
kernel-side thread support. @code{nscd} happens to hit these bugs
|
|
particularly hard, but you might have problems with any threaded
|
|
program.
|
|
|
|
@node Reporting Bugs
|
|
@appendixsec Reporting Bugs
|
|
@cindex reporting bugs
|
|
@cindex bugs, reporting
|
|
|
|
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.
|
|
|
|
It is a good idea to verify that the problem has not already been
|
|
reported. Bugs are documented in two places: The file @file{BUGS}
|
|
describes a number of well known bugs and the bug tracking system has a
|
|
WWW interface at
|
|
@url{http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl}. The WWW
|
|
interface gives you access to open and closed reports. The closed
|
|
reports normally include a patch or a hint on solving the problem.
|
|
|
|
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
|
|
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 (@pxref{Standards and
|
|
Portability}), that is definitely a bug. Report it!
|
|
|
|
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.
|
|
Do this using the @code{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).
|
|
@code{glibcbug} will insert the configuration information we need to
|
|
see, and ship the report off to @email{bugs@@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.
|
|
|
|
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 @email{bug-glibc-manual@@gnu.org}. If you refer to specific
|
|
sections of the manual, please include the section names for easier
|
|
identification.
|