* version.h (VERSION): Bump to 2.0.103.
This commit is contained in:
Ulrich Drepper 1998-11-20 17:27:47 +00:00
parent 5edb938769
commit d89e7a9637
3 changed files with 77 additions and 51 deletions

View File

@ -1,5 +1,7 @@
1998-11-20 Ulrich Drepper <drepper@cygnus.com> 1998-11-20 Ulrich Drepper <drepper@cygnus.com>
* version.h (VERSION): Bump to 2.0.103.
* aclocal.m4 (LIBC_PROG_BINUTILS): Also add AR and RANLIB using the * aclocal.m4 (LIBC_PROG_BINUTILS): Also add AR and RANLIB using the
same method. same method.
* configure.in: Don't define AR and RANLIB here. * configure.in: Don't define AR and RANLIB here.

124
FAQ.in
View File

@ -62,37 +62,35 @@ may not have all the features GNU libc requires. The current releases of
egcs (1.0.3 and 1.1) and GNU CC (2.8.1) should work with the GNU C library 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). (for powerpc see question ?powerpc).
{ZW} You may have problems if you try to mix code compiled with
EGCS and with GCC 2.8.1. See ?exception for details.
?? When I try to compile glibc I get only error messages. ?? When I try to compile glibc I get only error messages.
What's wrong? What's wrong?
{UD} You definitely need GNU make to translate GNU libc. No other make {UD} You definitely need GNU make to translate GNU libc. No other make
program has the needed functionality. program has the needed functionality.
We recommend version GNU make version 3.75. Versions 3.76 and 3.76.1 have We recommend version GNU make version 3.75 or 3.77. Versions before 3.75
bugs which appear when building big projects like GNU libc. Versions before have bugs and/or are missing features. Version 3.76 has bugs which
3.74 have bugs and/or are missing features. appear when building big projects like GNU libc. 3.76.1 appears to work but
some people have reported problems.
?? Do I need a special linker or archiver? ?? Do I need a special linker or assembler?
{UD} You may be able to use your system linker, but GNU libc works best with {ZW} If you want a shared library, you need a linker and assembler that
GNU binutils. understand all the features of ELF, including weak and versioned symbols.
The static library can be compiled with less featureful tools, but lacks key
features such as NSS.
On systems where the native linker does not support weak symbols you will For Linux or Hurd, you want binutils 2.8.1.0.23, 2.9.1, or 2.9.1.0.15 or
not get a fully ISO C compliant C library. Generally speaking you should higher. These are the only versions we've tested and found reliable. Other
use the GNU binutils if they provide at least the same functionality as your versions after 2.8.1.0.23 may work but we don't recommend them, especially
system's tools. not when C++ is involved. Earlier versions do not work at all.
Always get the newest release of GNU binutils available. Older releases are Other operating systems may come with system tools that have all the
known to have bugs that prevent a successful compilation. necessary features, but this is moot because glibc hasn't been ported to
them.
{AJ} Please don't use binutils 2.7. That release contains some bugs which
might make it necessary that you've got to recompile all your glibc2
binaries when upgrading the GNU C library.
{ZW} As of release 2.1 a linker supporting symbol versions is 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.
??powerpc Which compiler should I use for powerpc? ??powerpc Which compiler should I use for powerpc?
@ -107,7 +105,7 @@ variables. There is a temporary patch at:
Later versions of egcs may fix this problem. Later versions of egcs may fix this problem.
?? Do I need some more things to compile GNU C Library? ?? Do I need some more things to compile the GNU C Library?
{UD} Yes, there are some more :-). {UD} Yes, there are some more :-).
@ -117,15 +115,15 @@ Later versions of egcs may fix this problem.
site. (We distribute compiled message catalogs, but they may not be site. (We distribute compiled message catalogs, but they may not be
updated in patches.) updated in patches.)
* Some files depend on special tools. E.g., files ending in .gperf * Some files are built with special tools. E.g., files ending in .gperf
need a `gperf' program. The GNU version (part of libg++) is known need a `gperf' program. The GNU version (now available in a separate
to work while some vendor versions do not. package, formerly only as 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. You should not need these tools unless you change the source files.
* Some scripts need perl5 - but at the moment those scripts are not * Perl 5 is needed if you wish to test an installation of GNU libc
vital for building and installing GNU libc (some data files will not as the primary C library.
be created).
* When compiling for Linux, the header files of the Linux kernel must * When compiling for Linux, the header files of the Linux kernel must
be available to the compiler as <linux/*.h> and <asm/*.h>. be available to the compiler as <linux/*.h> and <asm/*.h>.
@ -167,7 +165,7 @@ recompile libc if you ever upgrade to kernel 2.1 or 2.2. To tell libc which
headers to use, give configure the --with-headers switch headers to use, give configure the --with-headers switch
(e.g. --with-headers=/usr/src/linux-2.1.107/include). (e.g. --with-headers=/usr/src/linux-2.1.107/include).
Note that you must configure the 2.1 kernel if you do this; otherwise libc Note that you must configure the 2.1 kernel if you do this, otherwise libc
will be unable to find <linux/version.h>. Just copy .config from your 2.0 will be unable to find <linux/version.h>. Just copy .config from your 2.0
kernel sources to the 2.1 tree, do `make oldconfig', and say no to all the kernel sources to the 2.1 tree, do `make oldconfig', and say no to all the
new options. new options.
@ -175,8 +173,9 @@ new options.
?? The compiler hangs while building iconvdata modules. What's ?? The compiler hangs while building iconvdata modules. What's
wrong? wrong?
{ZW} This is a problem of older GCC. Initialization of large static arrays {ZW} This is a problem with old versions of GCC. Initialization of large
is very slow. The compiler will eventually finish; give it time. static arrays is very slow. The compiler will eventually finish; give it
time.
The problem is fixed in egcs 1.1 but not in earlier releases. The problem is fixed in egcs 1.1 but not in earlier releases.
@ -526,6 +525,34 @@ not a symlink to libc.so.6. It should look something like this:
GROUP ( libc.so.6 libc_nonshared.a ) GROUP ( libc.so.6 libc_nonshared.a )
??exception When I run an executable on one system which I compiled on
another, I get dynamic linker errors. Both systems have the same
version of glibc installed. What's wrong?
{ZW} Glibc on one of these systems was compiled with gcc 2.7 or 2.8, the
other with egcs (any version). Egcs has functions in its internal
`libgcc.a' to support exception handling with C++. They are linked into
any program or dynamic library compiled with egcs, whether it needs them or
not. Dynamic libraries then turn around and export those functions again
unless special steps are taken to prevent them.
When you link your program, it resolves its references to the exception
functions to the ones exported accidentally by libc.so. That works fine as
long as libc has those functions. On the other system, libc doesn't have
those functions because it was compiled by gcc 2.8, and you get undefined
symbol errors. The symbols in question are named things like
`__register_frame_info'.
For glibc 2.0, the workaround is to not compile libc with egcs. We've also
incorporated a patch which should prevent the EH functions sneaking into
libc. It doesn't matter what compiler you use to compile your program.
For glibc 2.1, we've chosen to do it the other way around: libc.so
explicitly provides the EH functions. This is to prevent other shared
libraries from doing it. You must therefore compile glibc 2.1 with EGCS
unless you don't care about ever importing binaries from other systems.
Again, it doesn't matter what compiler you use for your programs.
?? How can I compile gcc 2.7.2.1 from the gcc source code using ?? How can I compile gcc 2.7.2.1 from the gcc source code using
glibc 2.x? glibc 2.x?
@ -627,7 +654,6 @@ db-Makefile'. Please note that not all services are capable of using a
database. Currently passwd, group, ethers, protocol, rpc, services shadow database. Currently passwd, group, ethers, protocol, rpc, services shadow
and netgroup are implemented. and netgroup are implemented.
?? I have /usr/include/net and /usr/include/scsi as symlinks ?? I have /usr/include/net and /usr/include/scsi as symlinks
into my Linux source tree. Is that wrong? into my Linux source tree. Is that wrong?
@ -680,18 +706,18 @@ So in case of doubt report such a warning message as a problem.
?? What do I need for C++ development? ?? What do I need for C++ development?
{HJ,AJ} You need either egcs 1.1 which comes directly with libstdc++ or {HJ,AJ} You need either egcs 1.1 which comes directly with libstdc++ or
gcc-2.8.1 together with libstdc++ 2.8.1.1. egcs 1.1 has the better C++ gcc-2.8.1 together with libstdc++ 2.8.1.1. egcs 1.1 has the better C++
support and works directly with glibc 2.1. If you use gcc-2.8.1 with support and works directly with glibc 2.1. If you use gcc-2.8.1 with
libstdc++ 2.8.1.1, you need to modify libstdc++ a bit. A patch is available libstdc++ 2.8.1.1, you need to modify libstdc++ a bit. A patch is available
as: as:
ftp://alpha.gnu.org/gnu/libstdc++-2.8.1.1-glibc2.1-diff.gz ftp://alpha.gnu.org/gnu/libstdc++-2.8.1.1-glibc2.1-diff.gz
Please note that libg++ 2.7.2 (and the Linux Versions 2.7.2.x) doesn't work Please note that 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 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 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) compiled for 2.0 is not compatible due to the new Large File Support (LFS)
in version 2.1. in version 2.1.
{UD} But since in the case of a shared libstdc++ the version numbers should {UD} But since in the case of a shared libstdc++ the version numbers should
be different existing programs will continue to work. be different existing programs will continue to work.
@ -742,13 +768,11 @@ really screwed up.
?? When I use nscd the machine freezes. ?? When I use nscd the machine freezes.
{UD} It is well known that you cannot use nscd with Linux 2.0.*. There {UD} You cannot use nscd with Linux 2.0.*. There is functionality missing
is functionality missing in the kernel and work-arounds are not suitable. in the kernel and work-arounds are not suitable. Besides, some parts of the
Beside this some parts of the kernel are too buggy when it comes to using kernel are too buggy when it comes to using threads.
threads.
So you have the possibilities to run Linux 2.0.* or update to a higher If you need nscd, you have to use a 2.1 kernel.
version and start using nscd.
Note that I have at this point no information about any other platform. Note that I have at this point no information about any other platform.

View File

@ -1,4 +1,4 @@
/* This file just defines the current version number of libc. */ /* This file just defines the current version number of libc. */
#define RELEASE "experimental" #define RELEASE "experimental"
#define VERSION "2.0.102" #define VERSION "2.0.103"