mirror of
https://sourceware.org/git/glibc.git
synced 2024-12-22 19:00:07 +00:00
f8cac037ee
* FAQ: New file contributed by drepper. * time/Makefile (headers): Add timebits.h. * sysdeps/unix/sysv/linux/timebits.h: New file. * sysdeps/stub/timebits.h: New file. * time/time.h (CLK_TCK): Define to CLOCKS_PER_SEC. (CLOCKS_PER_SEC): Remove this macro. Instead #include <timebits.h>.
141 lines
4.7 KiB
Plaintext
141 lines
4.7 KiB
Plaintext
Frequently Asked Question on GNU C Library
|
||
|
||
As every FAQ this one also tries to answer the questions the user
|
||
might when using the pacakge. Please make sure you read this before
|
||
sending questions/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 question which you think might be worth answered in
|
||
this document let me know.
|
||
|
||
--drepper@cygnus.com
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q1] ``What systems the GNU C Library runs 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
|
||
|
||
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
|
||
|
||
Roland McGrath <roland@gnu.ai.mit.edu>
|
||
or Ulrich Drepper <drepper@cygnus.com>
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q2] ``What compiler do I need to translate 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 mirrors.
|
||
|
||
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 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.
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q6] ``Do I need some more things to compile GNU C Library?''
|
||
|
||
[A6] {UD} Yes, there are some more :-).
|
||
|
||
* lots of diskspace (for i386-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 i386-linux on i586@133 or 2.5h or
|
||
i486@66).
|
||
|
||
If you have some more interested measurements let me know.
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
[Q7] ``When I run `nm libc.so|grep " U "' 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 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.
|
||
|
||
|
||
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
|
||
|
||
|
||
|
||
Answers were given by:
|
||
{UD} Ulrich Drepper, <drepper@cygnus.com>
|
||
|
||
|
||
Local Variables:
|
||
mode:text
|
||
End:
|