aboutsummaryrefslogtreecommitdiff
path: root/FAQ
diff options
context:
space:
mode:
authorUlrich Drepper <drepper@redhat.com>1998-01-30 12:53:20 +0000
committerUlrich Drepper <drepper@redhat.com>1998-01-30 12:53:20 +0000
commit4775243aa82ab568abe247e24ca56143683d64c2 (patch)
treeaffd0441d950fa21730d358e936169b81281ba7a /FAQ
parentcd897fe7c6c132e47d910d593ee330809d41d84a (diff)
downloadglibc-4775243aa82ab568abe247e24ca56143683d64c2.zip
glibc-4775243aa82ab568abe247e24ca56143683d64c2.tar.gz
glibc-4775243aa82ab568abe247e24ca56143683d64c2.tar.bz2
Update.
1998-01-28 Andreas Jaeger <aj@arthur.rhein-neckar.de> * manual/memory.texi (Heap Consistency Checking): mcheck is declared in <mcheck.h>. Suggested by Jochen Voss <voss@mathematik.uni-kl.de> [PR libc/438] 1998-01-28 Andreas Jaeger <aj@arthur.rhein-neckar.de> * sysdeps/generic/memmem.c (memmem): An empty needle is at the beginning of haystack. 1998-01-29 Andreas Jaeger <aj@arthur.rhein-neckar.de> * nss/nss_files/files-service.c: Correct last patch. 1998-01-30 21:29 Ulrich Drepper <drepper@cygnus.com> * sysdeps/unix/sysv/linux/sparc/sparc32/sigaction.c: Define __libc_have_rt_sigs. * sysdeps/sparc/sparc32/__longjmp.S: Define _SETJMP_H before including <bits/setjmp.h>. * sysdeps/sparc/sparc32/setjmp.S: Likewise. Patch from the Debian glibc/SPARC package. 1997-12-12 07:57 H.J. Lu <hjl@gnu.org> * sysdeps/alpha/bzero.S: Fix a typo. * sysdeps/alpha/htonl.S: Ditto. * sysdeps/alpha/htons.S: Ditto.
Diffstat (limited to 'FAQ')
-rw-r--r--FAQ164
1 files changed, 131 insertions, 33 deletions
diff --git a/FAQ b/FAQ
index bcca3ec..f8d462c 100644
--- a/FAQ
+++ b/FAQ
@@ -24,15 +24,18 @@ please let me know.
1.3. When I try to compile glibc I get only error messages.
What's wrong?
1.4. Do I need a special linker or archiver?
-1.5. Do I need some more things to compile GNU C Library?
-1.6. When I run `nm -u libc.so' on the produced library I still
+1.5. What tools do I need for powerpc?
+1.6. Do I need some more things to compile GNU C Library?
+1.7. When I run `nm -u libc.so' on the produced library I still
find unresolved symbols. Can this be ok?
-1.7. What are these `add-ons'?
-1.8. My XXX kernel emulates a floating-point coprocessor for me.
+1.8. What are these `add-ons'?
+1.9. My XXX kernel emulates a floating-point coprocessor for me.
Should I enable --with-fp?
-1.9. When compiling GNU libc I get lots of errors saying functions
+1.10. When compiling GNU libc I get lots of errors saying functions
in glibc are duplicated in libgcc.
-1.10. What's the problem with configure --enable-omitfp?
+1.11. Why do I get messages about missing thread functions when I use
+ the librt? I don't even use threads.
+1.12. What's the problem with configure --enable-omitfp?
2. Installation and configuration issues
@@ -90,6 +93,11 @@ please let me know.
3.7. Why don't signals interrupt system calls anymore?
3.8. I've got errors compiling code that uses certain string
functions. Why?
+3.9. I get compiler messages "Initializer element not constant" with
+ stdin/stdout/stderr. Why?
+3.10. I can't compile with gcc -traditional (or
+ -traditional-cpp). Why?
+3.11. I get some errors with `gcc -ansi'. Isn't glibc ANSI compatible?
4. Miscellaneous
@@ -114,12 +122,12 @@ 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
+ i[3456]86-*-linux-gnu Linux-2.x on Intel
+ m68k-*-linux-gnu Linux-2.x on Motorola 680x0
+ alpha-*-linux-gnu Linux-2.x 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
+ sparc-*-linux-gnu Linux-2.x on SPARC
+ sparc64-*-linux-gnu Linux-2.x 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.
@@ -129,7 +137,7 @@ 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>
+ <bug-glibc@gnu.org>
1.2. What compiler do I need to build GNU libc?
@@ -144,7 +152,8 @@ 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.
+supported platforms (for powerpc see question question 1.5), 2.7.2.3 is
+the earliest version that works at all.
1.3. When I try to compile glibc I get only error messages.
@@ -177,7 +186,28 @@ may have native linker support, but it's moot right now, because glibc
has not been ported to them.
-1.5. Do I need some more things to compile GNU C Library?
+1.5. What tools do I need for powerpc?
+
+{GK} For a successful installation you definitely need the most recent
+tools. You can safely assume that anything earlier than binutils
+2.8.1.0.17 and egcs-1.0 will have problems. We'd advise at the moment
+binutils 2.8.1.0.18 and egcs-1.0.1.
+
+In fact, egcs 1.0.1 currently has two serious bugs that prevent a
+clean make; one relates to switch statement folding, for which there
+is a temporary patch at
+
+<http://discus.anu.edu.au/~geoffk/egcs-1.0-geoffk.diff.gz>
+
+and the other relates to 'forbidden register spilled', for which the
+workaround is to put
+
+CFLAGS-condvar.c += -fno-inline
+
+in configparms. Later versions of egcs may fix these problems.
+
+
+1.6. Do I need some more things to compile GNU C Library?
{UD} Yes, there are some more :-).
@@ -193,6 +223,10 @@ has not been ported to them.
You should not need these tools unless you change the source files.
+* Some scripts need perl5 - but at the moment those scripts are not
+ vital for building and installing GNU libc (some data files will not
+ be created).
+
* When compiling for Linux, the header files of the Linux kernel must
be available to the compiler as <linux/*.h> and <asm/*.h>.
@@ -208,14 +242,15 @@ has not been ported to them.
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)
+ 45h34m for a full build (shared, static, and profiled) on Atari
+ Falcon (Motorola 68030 @ 16 Mhz, 14 Mb memory) and Jan Barte
+ <yann@plato.uni-paderborn.de> reports 22h48m on Atari TT030
+ (Motorola 68030 @ 32 Mhz, 34 Mb memory)
If you have some more measurements let me know.
-1.6. When I run `nm -u libc.so' on the produced library I still
+1.7. 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
@@ -235,7 +270,7 @@ Generally, you should make sure you find a real program which produces
errors while linking before deciding there is a problem.
-1.7. What are these `add-ons'?
+1.8. 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
@@ -259,7 +294,7 @@ just about anything else. The existing makefiles do most of the work;
only some few stub rules must be written to get everything running.
-1.8. My XXX kernel emulates a floating-point coprocessor for me.
+1.9. 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
@@ -273,7 +308,7 @@ far more trouble than it's worth: you then have to compile
(libgcc.a for GNU C), because the calling conventions change.
-1.9. When compiling GNU libc I get lots of errors saying functions
+1.10. 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
@@ -291,7 +326,24 @@ some problems of this kind. The setting of CFLAGS is checked at the
very beginning and if it is not usable `configure' will bark.
-1.10. What's the problem with configure --enable-omitfp?
+1.11. Why do I get messages about missing thread functions when I use
+ the librt? I don't even use threads.
+
+{UD} In this case you probably mixed up your installation of the libc.
+The librt internally uses threads and it has implicit references to
+the thread library. Normally these references are satisfied
+automatically but if the thread library belonging to the librt is not
+in the expected place one has to specify this place. When using GNU
+ld it works like this:
+
+ gcc -o foo foo.c -Wl,-rpath-link=/some/other/dir -lrt
+
+The `/some/other/dir' should contain the matching thread library and
+`ld' will use the given path to find the implicitly referenced library
+while not disturbing any other link path order.
+
+
+1.12. 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
@@ -414,7 +466,7 @@ See question 3.8 for details.
and source code. Until this law gets abolished we cannot ship the
cryptographic functions together with glibc.
-The functions are available, as an add-on (see question 1.7). People in the
+The functions are available, as an add-on (see question 1.8). People in the
US may get it from the same place they got GNU libc from. People
outside the US should get the code from ftp://ftp.ifi.uio.no/pub/gnu,
or another archive site outside the USA. The README explains how to
@@ -577,7 +629,7 @@ catalog files to the XPG4 form:
2.10. I have set up /etc/nis.conf, and the Linux libc 5 with NYS
works great. But the glibc NIS+ doesn't seem to work.
-{??} The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START
+{TK} The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START
file for storing information about the NIS+ server and their public
keys, because the nis.conf file does not contain all the necessary
information. You have to copy a NIS_COLD_START file from a Solaris
@@ -741,7 +793,7 @@ release is for. It's better to have a cut now than having no means to
support the new techniques later.
{MK} There is however a (partial) solution for this problem. Please
-take a look at the file `README.utmpd'.
+take a look at the file `login/README.utmpd'.
3.3. Where are the DST_* constants found in <sys/time.h> on many
@@ -789,13 +841,13 @@ results because of type conflicts.
still complains about redeclarations of types in the kernel
headers.
-{UD} The kernel headers before Linux 2.1.61 don't work correctly with
-glibc. Compiling C programs is possible in most cases but C++
-programs have (due to the change of the name lookups for `struct's)
-problems. One prominent example is `struct fd_set'.
+{UD} The kernel headers before Linux 2.1.61 and 2.0.32 don't work
+correctly with glibc. Compiling C programs is possible in most cases
+but C++ programs have (due to the change of the name lookups for
+`struct's) problems. One prominent example is `struct fd_set'.
-There might be some problems left but 2.1.61 fixes most of the known
-ones. See the BUGS file for other known problems.
+There might be some problems left but 2.1.61/2.0.32 fix most of the
+known ones. See the BUGS file for other known problems.
3.7. Why don't signals interrupt system calls anymore?
@@ -872,6 +924,50 @@ one can write
This disables the optimization for that specific call.
+
+3.9. I get compiler messages "Initializer element not constant" with
+ stdin/stdout/stderr. Why?
+
+{RM,AJ} Constructs like:
+static FILE *InPtr = stdin;
+
+lead to this message. This is correct behaviour with glibc since stdin
+is not a constant expression. Please note that a strict reading of ISO
+C does not allow above constructs.
+
+One of the advantages of this is that you can assign to stdin, stdout,
+and stderr just like any other global variable (e.g. `stdout =
+my_stream;'), which can be very useful with custom streams that you
+can write with libio (but beware this is not necessarily
+portable). The reason to implement it this way were versioning
+problems with the size of the FILE structure.
+
+
+3.10. I can't compile with gcc -traditional (or
+ -traditional-cpp). Why?
+
+{AJ} glibc2 does break -traditional and -traditonal-cpp - and will continue
+to do so. For example constructs of the form:
+enum {foo
+#define foo foo
+}
+are useful for debugging purpuses (you can use foo with your debugger
+that's why we need the enum) and for compatibility (other systems use
+defines and check with #ifdef).
+
+
+3.11. I get some errors with `gcc -ansi'. Isn't glibc ANSI compatible?
+
+{AJ} The GNU C library is compatible with the ANSI/ISO C standard. If
+you're using `gcc -ansi', the glibc includes which are specified in
+the standard follow the standard. The ANSI/ISO C standard defines what
+has to be in the include files - and also states that nothing else
+should be in the include files (btw. you can still enable additional
+standards with feature flags).
+
+The GNU C library is conforming to ANSI/ISO C - if and only if you're
+only using the headers and library functions defined in the standard.
+
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@@ -893,8 +989,8 @@ point where the headers are stable. There are still lots of
incompatible changes made and the libc headers have to follow.
Also, make sure you have a suitably recent kernel. As of the 970401
-snapshot, according to Philip Blundell <philb@gnu.ai.mit.edu>, the
-required kernel version is 2.1.30.
+snapshot, according to Philip Blundell <Philip.Blundell@pobox.com>, the
+required kernel version is at least 2.1.30.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
@@ -908,6 +1004,8 @@ Answers were given by:
{PB} Phil Blundell, <Philip.Blundell@pobox.com>
{MK} Mark Kettenis, <kettenis@phys.uva.nl>
{ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu>
+{TK} Thorsten Kukuk, <kukuk@vt.uni-paderborn.de>
+{GK} Geoffrey Keating, <Geoff.Keating@anu.edu.au>
Local Variables:
mode:outline