aboutsummaryrefslogtreecommitdiff
path: root/FAQ
diff options
context:
space:
mode:
Diffstat (limited to 'FAQ')
-rw-r--r--FAQ178
1 files changed, 123 insertions, 55 deletions
diff --git a/FAQ b/FAQ
index a54db10..e2b9f0d 100644
--- a/FAQ
+++ b/FAQ
@@ -26,16 +26,17 @@ please let me know.
1.4. Do I need a special linker or archiver?
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
+1.7. What version of the Linux kernel headers should be used?
+1.8. When I run `nm -u libc.so' on the produced library I still
find unresolved symbols. Can this be ok?
-1.8. What are these `add-ons'?
-1.9. My XXX kernel emulates a floating-point coprocessor for me.
+1.9. What are these `add-ons'?
+1.10. My XXX kernel emulates a floating-point coprocessor for me.
Should I enable --with-fp?
-1.10. When compiling GNU libc I get lots of errors saying functions
+1.11. When compiling GNU libc I get lots of errors saying functions
in glibc are duplicated in libgcc.
-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?
+1.12. Why do I get messages about missing thread functions when I use
+ librt? I don't even use threads.
+1.13. What's the problem with configure --enable-omitfp?
2. Installation and configuration issues
@@ -58,23 +59,28 @@ please let me know.
glibc 2.x?
2.9. The `gencat' utility cannot process the catalog sources which
were used on my Linux libc5 based system. Why?
-2.10. I have set up /etc/nis.conf, and the Linux libc 5 with NYS
+2.10. Programs using libc have their messages translated, but other
+ behavior is not localized (e.g. collating order); why?
+2.11. 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.
-2.11. I have killed ypbind to stop using NIS, but glibc will
- continue using NIS.
-2.12. After installing glibc name resolving doesn't work properly.
-2.13. I have /usr/include/net and /usr/include/scsi as symlinks
+2.12. I have killed ypbind to stop using NIS, but glibc
+ continues using NIS.
+2.13. Under Linux/Alpha, I always get "do_ypcall: clnt_call:
+ RPC: Unable to receive; errno = Connection refused" when using NIS.
+2.14. After installing glibc name resolving doesn't work properly.
+2.15. I have /usr/include/net and /usr/include/scsi as symlinks
into my Linux source tree. Is that wrong?
-2.14. Programs like `logname', `top', `uptime' `users', `w' and
+2.16. Programs like `logname', `top', `uptime' `users', `w' and
`who', show incorrect information about the (number of)
users on my system. Why?
-2.15. After upgrading to glibc 2.1 with symbol versioning I get
+2.17. After upgrading to glibc 2.1 with symbol versioning I get
errors about undefined symbols. What went wrong?
-2.16. When I start the program XXX after upgrading the library
+2.18. When I start the program XXX after upgrading the library
I get
XXX: Symbol `_sys_errlist' has different size in shared
object, consider re-linking
Why? What should I do?
+2.19. What do I need for C++ development?
3. Source and binary incompatibilities, and what to do about them
@@ -100,6 +106,8 @@ please let me know.
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.12. I can't access some functions anymore. nm shows that they do
+ exist but linking fails nevertheless.
4. Miscellaneous
@@ -148,14 +156,14 @@ you are really interested in porting it, contact
GNU CC are used to increase portability and speed.
GNU CC is found, like all other GNU packages, on
- ftp://prep.ai.mit.edu/pub/gnu
-and the many mirror sites. prep is always overloaded, so try to find
+ ftp://ftp.gnu.org/pub/gnu
+and the many mirror sites. ftp.gnu.org is always overloaded, so try to find
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 (for powerpc see question question 1.5), 2.7.2.3 is
-the earliest version that works at all.
+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 question 1.5).
1.3. When I try to compile glibc I get only error messages.
@@ -183,7 +191,7 @@ Always get the newest release of GNU binutils available. Older
releases are known to have bugs that prevent a successful compilation.
{ZW} As of release 2.1 a linker supporting symbol versions is
-required. For Linux, get binutils-2.8.1.0.17 or later. Other systems
+required. For Linux, get binutils-2.8.1.0.23 or later. Other systems
may have native linker support, but it's moot right now, because glibc
has not been ported to them.
@@ -215,7 +223,7 @@ in configparms. Later versions of egcs may fix these problems.
* GNU gettext. This package contains the tools needed to construct
`message catalog' files containing translated versions of system
- messages. See ftp://prep.ai.mit.edu/pub/gnu or better any mirror
+ messages. See ftp://ftp.gnu.org/pub/gnu or better any mirror
site. (We distribute compiled message catalogs, but they may not be
updated in patches.)
@@ -252,7 +260,19 @@ in configparms. Later versions of egcs may fix these problems.
If you have some more measurements let me know.
-1.7. When I run `nm -u libc.so' on the produced library I still
+1.7. What version of the Linux kernel headers should be used?
+
+{AJ,UD} The headers from the most recent Linux kernel should be used.
+The headers used while compiling the GNU C library and the kernel
+binary used when using the library do not need to match. The GNU C
+library runs without problems on kernels that are older than the
+kernel headers used. The other way round (compiling the GNU C library
+with old kernel headers and running on a recent kernel) does not
+necessarily work. For example you can't use new kernel features when
+using old kernel headers for compiling the GNU C library.
+
+
+1.8. 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
@@ -272,7 +292,7 @@ Generally, you should make sure you find a real program which produces
errors while linking before deciding there is a problem.
-1.8. What are these `add-ons'?
+1.9. 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
@@ -296,7 +316,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.9. My XXX kernel emulates a floating-point coprocessor for me.
+1.10. 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
@@ -310,7 +330,7 @@ far more trouble than it's worth: you then have to compile
(libgcc.a for GNU C), because the calling conventions change.
-1.10. When compiling GNU libc I get lots of errors saying functions
+1.11. 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
@@ -328,24 +348,23 @@ 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.11. Why do I get messages about missing thread functions when I use
- the librt? I don't even use threads.
+1.12. Why do I get messages about missing thread functions when I use
+ 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:
+{UD} In this case you probably mixed up your installation. librt uses
+threads internally and has implicit references to the thread library.
+Normally these references are satisfied automatically but if the
+thread library is not in the expected place you must tell the linker
+where it is. 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.
+The `/some/other/dir' should contain the thread library. `ld' will
+use the given path to find the implicitly referenced library while not
+disturbing any other link path.
-1.12. What's the problem with configure --enable-omitfp?
+1.13. 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
@@ -468,7 +487,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.8). People in the
+The functions are available, as an add-on (see question 1.9). 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
@@ -588,9 +607,9 @@ GROUP ( libc.so.6 ld-linux.so.2 libc.a )
2.8. How can I compile gcc 2.7.2.1 from the gcc source code using
glibc 2.x?
-{AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3
-or later. You should get at least gcc 2.7.2.3. All previous versions
-had problems with glibc support.
+{AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3 or
+later. But you should get at least gcc 2.8.1 or egcs 1.0.2 (or later
+versions) instead.
2.9. The `gencat' utility cannot process the catalog sources which
@@ -628,7 +647,21 @@ catalog files to the XPG4 form:
-----------------------------------------------------------------------
-2.10. I have set up /etc/nis.conf, and the Linux libc 5 with NYS
+2.10. Programs using libc have their messages translated, but other
+ behavior is not localized (e.g. collating order); why?
+
+{ZW} Translated messages are automatically installed, but the locale
+database that controls other behaviors is not. You need to run
+localedef to install this database, after you have run `make
+install'. For example, to set up the French Canadian locale, simply
+issue the command
+
+ localedef -i fr_CA -f ISO-8859-1 fr_CA
+
+Please see localedata/README in the source tree for further details.
+
+
+2.11. 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.
{TK} The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START
@@ -640,24 +673,33 @@ 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
- continue using NIS.
+2.12. I have killed ypbind to stop using NIS, but glibc
+ continues using NIS.
{TK} For faster NIS lookups, glibc uses the /var/yp/binding/ files
from ypbind. ypbind 3.3 and older versions don't always remove these
-files, so glibc will use them furthermore. Other BSD versions seem to
-work correct. Until ypbind 3.4 is released, you can find a patch at
-ftp://ftp.kernel.org/pub/linux/utils/net/NIS/ypbind-3.3-glibc2.diff.
+files, so glibc will continue to use them. Other BSD versions seem to
+work correctly. Until ypbind 3.4 is released, you can find a patch at
+ftp://ftp.kernel.org/pub/linux/utils/net/NIS/ypbind-3.3-glibc3.diff.
+
+2.13. Under Linux/Alpha, I always get "do_ypcall: clnt_call:
+ RPC: Unable to receive; errno = Connection refused" when using NIS.
-2.12. After installing glibc name resolving doesn't work properly.
+{TK} You need a ypbind version which is 64bit clean. Some versions
+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.14. After installing glibc name resolving doesn't work properly.
{AJ} You probably should read the manual section describing
nsswitch.conf (just type `info libc "NSS Configuration File"').
The NSS configuration file is usually the culprit.
-2.13. I have /usr/include/net and /usr/include/scsi as symlinks
+2.15. I have /usr/include/net and /usr/include/scsi as symlinks
into my Linux source tree. Is that wrong?
{PB} This was necessary for libc5, but is not correct when using
@@ -668,14 +710,14 @@ any symlink that you have in place before you install glibc. However,
/usr/include/asm and /usr/include/linux should remain as they were.
-2.14. Programs like `logname', `top', `uptime' `users', `w' and
+2.16. Programs like `logname', `top', `uptime' `users', `w' and
`who', show incorrect information about the (number of)
users on my system. Why?
{MK} See question 3.2.
-2.15. After upgrading to glibc 2.1 with symbol versioning I get
+2.17. After upgrading to glibc 2.1 with symbol versioning I get
errors about undefined symbols. What went wrong?
{AJ} The problem is caused either by wrong program code or tools. In
@@ -689,7 +731,7 @@ the price you might have to pay once for quite a number of advantages
with symbol versioning.
-2.16. When I start the program XXX after upgrading the library
+2.18. When I start the program XXX after upgrading the library
I get
XXX: Symbol `_sys_errlist' has different size in shared
object, consider re-linking
@@ -711,6 +753,16 @@ might be possible that a symbol changed size when that should not have
happened. So in case of doubt report such a warning message as a
problem.
+
+2.19. What do I need for C++ development?
+
+{HJ,AJ} You need either egcs 1.0.2 or gcc-2.8.1 with libstdc++
+2.8.1 (or more recent versions). libg++ 2.7.2 (and the Linux Versions
+2.7.2.x) doesn't work very well with the GNU C library due to vtable thunks.
+If you're upgrading from glibc 2.0.x to 2.1 you have to recompile
+libstdc++ since the library compiled for 2.0 is not compatible due to the new
+Large File Support (LFS) in version 2.1.
+
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@@ -963,7 +1015,7 @@ 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
+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).
@@ -980,6 +1032,21 @@ 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.12. I can't access some functions anymore. nm shows that they do
+ exist but linking fails nevertheless.
+
+{AJ} With the introduction of versioning in glibc 2.1 it is possible
+to export only those identifiers (functions, variables) that are
+really needed by application programs and by other parts of glibc.
+This way a lot of internal interfaces are now hidden. nm will still
+show those identifiers but marking them as internal. ISO C states
+that identifiers beginning with an underscore are internal to the
+libc. An application program normally shouldn't use those internal
+interfaces (there are exceptions, e.g. __ivaliduser). If a program
+uses these interfaces, it's broken. These internal interfaces might
+change between glibc releases or dropped completely.
+
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@@ -989,7 +1056,7 @@ only using the headers and library functions defined in the standard.
or higher is required for this script'. What can I do?
{UD} You have to get the specified autoconf version (or a later one)
-from your favorite mirror of prep.ai.mit.edu.
+from your favorite mirror of ftp.gnu.org.
4.2. When I try to compile code which uses IPv6 headers and
@@ -1018,6 +1085,7 @@ Answers were given by:
{ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu>
{TK} Thorsten Kukuk, <kukuk@vt.uni-paderborn.de>
{GK} Geoffrey Keating, <Geoff.Keating@anu.edu.au>
+{HJ} H.J. Lu, <hjl@gnu.org>
Local Variables:
mode:outline