mirror of
git://sourceware.org/git/glibc.git
synced 2025-04-06 14:10:30 +08:00
Update.
This commit is contained in:
parent
b1d4191b04
commit
416f29d621
77
FAQ
77
FAQ
@ -77,6 +77,8 @@ please let me know.
|
||||
continues using NIS.
|
||||
2.19. Under Linux/Alpha, I always get "do_ypcall: clnt_call:
|
||||
RPC: Unable to receive; errno = Connection refused" when using NIS.
|
||||
2.22. I just upgraded my Linux system to glibc and now I get
|
||||
errors whenever I try to link any program.
|
||||
|
||||
3. Source and binary incompatibilities, and what to do about them
|
||||
|
||||
@ -95,6 +97,10 @@ please let me know.
|
||||
still complains about redeclarations of types in the kernel
|
||||
headers.
|
||||
3.7. Why don't signals interrupt system calls anymore?
|
||||
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?
|
||||
|
||||
3.14. The pow() inline function I get when including <math.h> is broken.
|
||||
I get segmentation faults when I run the program.
|
||||
|
||||
@ -441,14 +447,14 @@ libc binaries from the US.
|
||||
the libc.so which comes with glibc all I get is a core dump.
|
||||
|
||||
{UD} On Linux, gcc sets the dynamic linker to /lib/ld-linux.so.1
|
||||
unless the user specifies a -dynamic-linker argument. This is the
|
||||
unless the 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 to the linker
|
||||
--dynamic-linker=/lib/ld-linux.so.2
|
||||
|
||||
which is the glibc dynamic linker, on Linux systems. On other systems
|
||||
name is /lib/ld.so.1. When linking via gcc, you've got to add
|
||||
the 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.
|
||||
@ -596,7 +602,7 @@ it with nisinit from the nis-tools package (available at
|
||||
http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html).
|
||||
|
||||
|
||||
+2.11. I have killed ypbind to stop using NIS, but glibc will
|
||||
2.11. I have killed ypbind to stop using NIS, but glibc will
|
||||
continue using NIS.
|
||||
|
||||
{TK} For faster NIS lookups, glibc uses the /var/yp/binding/ files
|
||||
@ -697,6 +703,19 @@ are not 64bit clean. A 64bit clean implementation is ypbind-mt. For
|
||||
ypbind 3.3, you need the patch from ftp.kernel.org (See the previous
|
||||
question). I don't know about other versions.
|
||||
|
||||
2.22. I just upgraded my Linux system to glibc and now I get
|
||||
errors whenever I try to link any program.
|
||||
|
||||
{ZW} This happens when you have installed glibc as the primary C library but
|
||||
have stray symbolic links pointing at your old C library. If the first
|
||||
`libc.so' the linker finds is libc 5, it will use that. Your program
|
||||
expects to be linked with glibc, so the link fails.
|
||||
|
||||
The most common case is that glibc put its `libc.so' in /usr/lib, but there
|
||||
was a `libc.so' from libc 5 in /lib, which gets searched first. To fix the
|
||||
problem, just delete /lib/libc.so. You may also need to delete other
|
||||
symbolic links in /lib, such as /lib/libm.so if it points to libm.so.5.
|
||||
|
||||
|
||||
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
|
||||
|
||||
@ -884,6 +903,34 @@ and return EINTR (for example, to implement a timeout) you can do this with
|
||||
siginterrupt().
|
||||
|
||||
|
||||
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 purposes (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.
|
||||
|
||||
|
||||
3.14. The pow() inline function I get when including <math.h> is broken.
|
||||
I get segmentation faults when I run the program.
|
||||
|
||||
@ -918,6 +965,30 @@ snapshot, according to Philip Blundell <Philip.Blundell@pobox.com>, the
|
||||
required kernel version is at least 2.1.30.
|
||||
|
||||
|
||||
4.3. When I set the timezone by setting the TZ environment variable
|
||||
to EST5EDT things go wrong since glibc computes the wrong time
|
||||
from this information.
|
||||
|
||||
{UD} The problem is that people still use the braindamaged POSIX method to
|
||||
select the timezone using the TZ environment variable with a format EST5EDT
|
||||
or whatever. People, read the POSIX standard, the implemented behaviour is
|
||||
correct! What you see is in fact the result of the decisions made while
|
||||
POSIX.1 was created. We've only implemented the handling of TZ this way to
|
||||
be POSIX compliant. It is not really meant to be used.
|
||||
|
||||
The alternative approach to handle timezones which is implemented is the
|
||||
correct one to use: use the timezone database. This avoids all the problems
|
||||
the POSIX method has plus it is much easier to use. Simply run the tzselect
|
||||
hell script, answer the question and use the name printed in the end by
|
||||
making a symlink to /usr/share/zoneinfo/NAME (NAME is the returned value
|
||||
from tzselect) from the file /etc/localtime. That's all. You never again
|
||||
have to worry.
|
||||
|
||||
So, please avoid sending bug reports about time related problems if you use
|
||||
the POSIX method and you have not verified something is really broken by
|
||||
reading the POSIX standards.
|
||||
|
||||
|
||||
4.4. What other sources of documentation about glibc are available?
|
||||
|
||||
{AJ} The FSF has a page about the GNU C library at
|
||||
|
Loading…
x
Reference in New Issue
Block a user