352 lines
14 KiB
Plaintext
352 lines
14 KiB
Plaintext
Frequently Asked Question on GNU C Library
|
||
|
||
As every FAQ this one also tries to answer questions the user might have
|
||
when using the package. Please make sure you read this before sending
|
||
questions or bug reports to the maintainers.
|
||
|
||
The GNU C Library is very complex. The building process exploits the
|
||
features available in tools generally available. But many things can
|
||
only be done using GNU tools. Also the code is sometimes hard to
|
||
understand because it has to be portable but on the other hand must be
|
||
fast. But you need not understand the details to use GNU C Library.
|
||
This will only be necessary if you intend to contribute or change it.
|
||
|
||
If you have any questions you think should be answered in this document,
|
||
please let me know.
|
||
|
||
--drepper@cygnus.com
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q1] ``What systems does the GNU C Library run on?''
|
||
|
||
[Q2] ``What compiler do I need to build GNU libc?''
|
||
|
||
[Q3] ``When starting make I get only error messages.
|
||
What's wrong?''
|
||
|
||
[Q4] ``After I changed configure.in I get `Autoconf version X.Y.
|
||
or higher is required for this script'. What can I do?''
|
||
|
||
[Q5] ``Do I need a special linker or archiver?''
|
||
|
||
[Q6] ``Do I need some more things to compile GNU C Library?''
|
||
|
||
[Q7] ``When I run `nm -u libc.so' on the produced library I still
|
||
find unresolved symbols? Can this be ok?''
|
||
|
||
[Q8] ``Can I replace the libc on my Linux system with GNU libc?''
|
||
|
||
[Q9] ``I expect GNU libc to be 100% source code compatible with
|
||
the old Linux based GNU libc. Why isn't it like this?''
|
||
|
||
[Q10] ``Why does getlogin() always return NULL on my Linux box?''
|
||
|
||
[Q11] ``Where are the DST_* constants found in <sys/time.h> on many
|
||
systems?''
|
||
|
||
[Q12] ``The `gencat' utility cannot process the input which are
|
||
successfully used on my Linux libc based system. Why?''
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q1] ``What systems does the GNU C Library run on?''
|
||
|
||
[A1] {UD} This is difficult to answer. The file `README' lists the
|
||
architectures GNU libc is known to run *at some time*. This does not
|
||
mean that it still can be compiled and run on them in the moment.
|
||
|
||
The systems glibc is known to work on in the moment and most probably
|
||
in the future are:
|
||
|
||
*-*-gnu GNU Hurd
|
||
i[3456]86-*-linux Linux-2.0 on Intel
|
||
m68k-*-linux Linux-2.0 on Motorola 680x0
|
||
alpha-*-linux Linux-2.0 on DEC Alpha
|
||
|
||
Other Linux platforms are also on the way to be supported but I need
|
||
some success reports first.
|
||
|
||
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>
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q2] ``What compiler do I need to build GNU libc?''
|
||
|
||
[A2] {UD} It is (almost) impossible to compile GNU C Library using a
|
||
different compiler than GNU CC. A lot of extensions of GNU CC are
|
||
used to increase the portability and speed.
|
||
|
||
But this does not mean you have to use GNU CC for using the GNU C
|
||
Library. In fact you should be able to use the native C compiler
|
||
because the success only depends on the binutils: the linker and
|
||
archiver.
|
||
|
||
The GNU CC is found like all other GNU packages on
|
||
ftp://prep.ai.mit.edu/pub/gnu
|
||
or better one of the many mirror sites.
|
||
|
||
You always should try to use the latest official release. Older
|
||
versions might not have all the features GNU libc could use.
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q3] ``When starting `make' I get only errors messages.
|
||
What's wrong?''
|
||
|
||
[A3] {UD} You definitely need GNU make to translate GNU libc. No
|
||
other make program has the needed functionality.
|
||
|
||
Versions before 3.74 have bugs which prevent correct execution so you
|
||
should upgrade to the latest version before starting the compilation.
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q4] ``After I changed configure.in I get `Autoconf version X.Y.
|
||
or higher is required for this script'. What can I do?''
|
||
|
||
[A4] {UD} You have to get the specified autoconf version (or a later)
|
||
from your favourite mirror of prep.ai.mit.edu.
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q5] ``Do I need a special linker or archiver?''
|
||
|
||
[A5] {UD} If your native versions are not too buggy you can probably
|
||
work with them. But GNU libc works best with GNU binutils.
|
||
|
||
On systems where the native linker does not support weak symbols you
|
||
will not get a really 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 affect building the GNU C
|
||
Library.
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q6] ``Do I need some more things to compile GNU C Library?''
|
||
|
||
[A6] {UD} Yes, there are some more :-).
|
||
|
||
* GNU gettext; the GNU libc is internationalized and partly localized.
|
||
For bringing the messages for the different languages in the needed
|
||
form the tools from the GNU gettext package are necessary. See
|
||
ftp://prep.ai.mit.edu/pub/gnu or better any mirror site.
|
||
|
||
* lots of diskspace (for i?86-linux this means, e.g., ~70MB).
|
||
|
||
You should avoid compiling on a NFS mounted device. This is very
|
||
slow.
|
||
|
||
* plenty of time (approx 1h for i?86-linux on i586@133 or 2.5h on
|
||
i486@66 or 4.5h on i486@33).
|
||
|
||
If you have some more measurements let me know.
|
||
|
||
* 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.
|
||
|
||
* When compiling for Linux:
|
||
|
||
+ the header files of the Linux kernel must be available in the
|
||
search path of the CPP as <linux/*.h> and <asm/*.h>.
|
||
|
||
* 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.
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q7] ``When I run `nm -u libc.so' on the produced library I still
|
||
find unresolved symbols? Can this be ok?''
|
||
|
||
[A7] {UD} Yes, this is ok. There can be several kinds of unresolved
|
||
symbols:
|
||
|
||
* magic symbols automatically generated by the linker. Names are
|
||
often 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
|
||
(currently fabs among others; this gets resolved if the program
|
||
is linked against libm, too.)
|
||
|
||
Generally, you should make sure you find a real program which produces
|
||
errors while linking before deciding there is a problem.
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q8] ``Can I replace the libc on my Linux system with GNU libc?''
|
||
|
||
[A8] {UD} You cannot replace any existing libc for Linux with GNU
|
||
libc. There are different versions of C libraries and you can run
|
||
libcs with different major version independently.
|
||
|
||
For Linux there are today two libc versions:
|
||
libc-4 old a.out libc
|
||
libc-5 current ELF libc
|
||
|
||
GNU libc will have the major number 6 and therefore you can have this
|
||
additionally 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.
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q9] ``I expect GNU libc to be 100% source code compatible with
|
||
the old Linux based GNU libc. Why isn't it like this?''
|
||
|
||
[A9] {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 now can be corrected. Here is a list of the known source code
|
||
incompatibilities:
|
||
|
||
* _GNU_SOURCE: glibc does not automatically define _GNU_SOURCE. Thus,
|
||
if a program depends on GNU extensions or some other non-standard
|
||
functionality, it is necessary to compile it with 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' part of the GNU C
|
||
library sources.
|
||
|
||
* reboot(): GNU libc sanitizes the interface of reboot() to be more
|
||
compatible with the interface used on other OSes. In particular,
|
||
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 changed, but the
|
||
prototype is in a separate header file <sys/swap.h>. For the additional
|
||
argument of of swapon() you should use the SWAP_* constants from
|
||
<linux/swap.h>, which get defined when <sys/swap.h> is included.
|
||
|
||
* errno: If a program uses variable "errno", then it _must_ include header
|
||
file <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 the references of the 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 tables 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>
|
||
create_module create_module <sys/module.h>
|
||
delete_module delete_module <sys/module.h>
|
||
get_kernel_syms get_kernel_syms <sys/module.h>
|
||
init_module init_module <sys/module.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 interfaces. 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 the libc itself. There is
|
||
a separate library libresolv. If you find some symbols starting with
|
||
`res_*' undefined simply add -lresolv to your call of the linker.
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q10] ``Why does getlogin() always return NULL on my Linux box?''
|
||
|
||
[A10] {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. So the
|
||
record size is different, fields might have a different position and
|
||
so reading 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.
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
|
||
[Q11] ``Where are the DST_* constants found in <sys/time.h> on many
|
||
systems?''
|
||
|
||
[A11] {UD} These constants come from the old BSD days and are not used
|
||
today anymore (even the Linux based glibc does not implement the handling
|
||
although the constants are defined).
|
||
|
||
Instead GNU libc contains the zone database handling and compatibility
|
||
code for POSIX TZ environment variable handling.
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
|
||
[Q12] ``The `gencat' utility cannot process the input which are
|
||
successfully used on my Linux libc based system. Why?''
|
||
|
||
[A12] {UD} Unlike the author of the `gencat' program which is distributed
|
||
with Linux libc I have read the underlying standards before writing the
|
||
code. It is completely compatible with the specification given in
|
||
X/Open Portability Guide.
|
||
|
||
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/
|
||
}
|
||
-----------------------------------------------------------------------
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
|
||
Answers were given by:
|
||
{UD} Ulrich Drepper, <drepper@cygnus.com>
|
||
{DMT} David Mosberger-Tang, <davidm@AZStarNet.com>
|
||
|
||
Amended by:
|
||
{RM} Roland McGrath, <roland@gnu.ai.mit.edu>
|
||
|
||
Local Variables:
|
||
mode:text
|
||
End:
|