aboutsummaryrefslogtreecommitdiff
path: root/FAQ
diff options
context:
space:
mode:
Diffstat (limited to 'FAQ')
-rw-r--r--FAQ39
1 files changed, 29 insertions, 10 deletions
diff --git a/FAQ b/FAQ
index a855028..f2e41f5 100644
--- a/FAQ
+++ b/FAQ
@@ -63,6 +63,11 @@ please let me know.
functions `stat', `lstat', `fstat', and `mknod' and while
linking on my Linux system I get error messages. How is
this supposed to work?''
+
+[Q18] ``The prototypes for `connect', `accept', `getsockopt',
+ `setsockopt', `getsockname', `getpeername', `send',
+ `sendto', and `recvfrom' are different in GNU libc than
+ on any other system I saw. This is a bug, isn't it?''
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
[Q1] ``What systems does the GNU C Library run on?''
@@ -75,9 +80,9 @@ 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
+ 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
Other Linux platforms are also on the way to be supported but I need
some success reports first.
@@ -159,14 +164,10 @@ Library.
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).
+ i486@66 or 4.5h on i486@33). For Hurd systems times are much higher.
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
@@ -176,6 +177,8 @@ Library.
need a `gperf' program. The GNU version (part of libg++) is known
to work while some vendor versions do not.
+ You should not need these tools unless you change the source files.
+
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
[Q7] ``When I run `nm -u libc.so' on the produced library I still
find unresolved symbols? Can this be ok?''
@@ -407,7 +410,7 @@ libc binaries from the US.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
[Q15] ``What are these `add-ons'?''
-[A15] {UD} To avoid complications with external or external source
+[A15] {UD} To avoid complications with export rules or external source
code some optional parts of the libc are distributed as separate
packages (e.g., the crypt package, see Q14).
@@ -416,7 +419,7 @@ the package and tell the configuration script about these additional
subdirectories using the --enable-add-ons option. When you add the
crypt add-on you just have to use
- configure --enable-add-ons=crypt,XXX ...
+ configure --enable-add-ons=des-crypt,XXX ...
where XXX are possible other add-ons and ... means the rest of the
normal option list.
@@ -552,6 +555,22 @@ link. The linker script with the above contents is placed in
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
+[Q18] ``The prototypes for `connect', `accept', `getsockopt',
+ `setsockopt', `getsockname', `getpeername', `send',
+ `sendto', and `recvfrom' are different in GNU libc from
+ any other system I saw. This is a bug, isn't it?''
+
+[A18] {UD} No, this is no bug. This version of the GNU libc already
+follows the to-be-released POSIX.1g standard. In this standard
+the type `size_t' is used for all parameters which describe a size.
+So better change now.
+
+This change is critical for system which have
+ sizeof (int) != sizeof (size_t)
+like the Alpha.
+
+
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Answers were given by:
{UD} Ulrich Drepper, <drepper@cygnus.com>