aboutsummaryrefslogtreecommitdiff
path: root/FAQ.in
diff options
context:
space:
mode:
authorUlrich Drepper <drepper@redhat.com>1998-09-23 15:28:54 +0000
committerUlrich Drepper <drepper@redhat.com>1998-09-23 15:28:54 +0000
commita379e56acc0955dd1ec03740cfbb632ce54b7416 (patch)
tree408e9a4ab3aa25628e67dec3b09448eee54a4054 /FAQ.in
parent34a4b66d934c5aa8d413073f0df773ed5830c05b (diff)
downloadglibc-a379e56acc0955dd1ec03740cfbb632ce54b7416.zip
glibc-a379e56acc0955dd1ec03740cfbb632ce54b7416.tar.gz
glibc-a379e56acc0955dd1ec03740cfbb632ce54b7416.tar.bz2
Update.
1998-09-23 15:25 Ulrich Drepper <drepper@cygnus.com> * libio/stdio.h: Define __need_getopt and include getopt.h to define getopt stuff. * posix/unistd.h: Likewise. * stdio/stdio.h: Likewise. * posix/getopt.h: Remove _GNU_SOURCE use. If __need_getopt is defined define only getopt and the variables. (CPPFLAGS): Add -DUSE_LIBDB1
Diffstat (limited to 'FAQ.in')
-rw-r--r--FAQ.in27
1 files changed, 14 insertions, 13 deletions
diff --git a/FAQ.in b/FAQ.in
index 75992ef..36228ea 100644
--- a/FAQ.in
+++ b/FAQ.in
@@ -59,8 +59,8 @@ a local mirror first.
You should always try to use the latest official release. Older versions
may not have all the features GNU libc requires. The current releases of
-egcs (1.0.2) and GNU CC (2.8.1) should work with the GNU C library (for
-powerpc see question ?powerpc).
+egcs (1.0.3 and 1.1) and GNU CC (2.8.1) should work with the GNU C library
+(for powerpc see question ?powerpc).
?? When I try to compile glibc I get only error messages.
What's wrong?
@@ -176,11 +176,10 @@ new options.
?? The compiler hangs while building iconvdata modules. What's
wrong?
-{ZW} This is a problem with all current releases of GCC. Initialization of
-large static arrays is very slow. The compiler will eventually finish; give
-it time.
+{ZW} This is a problem of older GCC. Initialization of large static arrays
+is very slow. The compiler will eventually finish; give it time.
-The problem will be fixed in egcs 1.1 but probably not before then.
+The problem is fixed in egcs 1.1 but not in earlier releases.
?? When I run `nm -u libc.so' on the produced library I still
find unresolved symbols. Can this be ok?
@@ -295,10 +294,9 @@ command line which failed and run the test from the subdirectory for this
test in the sources.
There are some failures which are not directly related to the GNU libc:
-- Some compiler produce buggy code. The current egcs snapshots are ok and
- the not yet released egcs 1.1 should be ok. gcc 2.8.1 might cause some
- failures, gcc 2.7.2.x is so buggy, that explicit checks have been used so
- that you can't build with it.
+- Some compiler produce buggy code. The egcs 1.1 release should be ok. gcc
+ 2.8.1 might cause some failures, gcc 2.7.2.x is so buggy, that explicit
+ checks have been used so that you can't build with it.
- The kernel might have bugs. For example on Linux/Alpha 2.0.34 the
floating point handling has quite a number of bugs and therefore most of
the test cases in the math subdirectory will fail. The current Linux 2.1
@@ -435,11 +433,14 @@ US.
user specifies a -dynamic-linker argument. This is the name of the libc5
dynamic linker, which does not work with glibc.
-For casual use of GNU libc you can just specify
- -dynamic-linker=/lib/ld-linux.so.2
+For casual use of GNU libc you can just specify to the linker
+ --dynamic-linker=/lib/ld-linux.so.2
which is the glibc dynamic linker, on Linux systems. On other systems the
-name is /lib/ld.so.1.
+name is /lib/ld.so.1. When linking via gcc, you've got to add
+ -Wl,--dynamic-linker=/lib/ld-linux.so.2
+
+to the gcc command line.
To change your environment to use GNU libc for compiling you need to change
the `specs' file of your gcc. This file is normally found at