Update.
1999-02-04 Ulrich Drepper <drepper@cygnus.com> * stdlib/strtoll.c: Add alias __strtoq_internal. * stdlib/strtoull.c: Add alias __strtouq_internal. * wcsmbs/mbrtowc.c: Correct logic testing for converted NUL character. Patch by Owen Taylor <otaylor@redhat.com>.
This commit is contained in:
Ulrich Drepper
parent
05c83ef1c1
commit
b8f558b7ac
|
|
@ -1,3 +1,11 @@
|
|||
1999-02-04 Ulrich Drepper <drepper@cygnus.com>
|
||||
|
||||
* stdlib/strtoll.c: Add alias __strtoq_internal.
|
||||
* stdlib/strtoull.c: Add alias __strtouq_internal.
|
||||
|
||||
* wcsmbs/mbrtowc.c: Correct logic testing for converted NUL
|
||||
character. Patch by Owen Taylor <otaylor@redhat.com>.
|
||||
|
||||
1999-02-03 Mark Kettenis <kettenis@gnu.org>
|
||||
|
||||
* sysdeps/mach/hurd/utimes.c (__utimes): Deal with TVP being NULL.
|
||||
|
|
|
|||
13
FAQ
13
FAQ
|
|
@ -203,11 +203,11 @@ 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.3 and 1.1) and GNU CC (2.8.1) should work with the GNU C library
|
||||
(for powerpc see question 1.5; for ARM see question 1.6).
|
||||
egcs (1.0.3 and 1.1.1) should work with the GNU C library (for powerpc see
|
||||
question 1.5; for ARM see question 1.6).
|
||||
|
||||
{ZW} You may have problems if you try to mix code compiled with
|
||||
EGCS and with GCC 2.8.1. See question 2.8 for details.
|
||||
{ZW} Due to problems with C++ exception handling, you must use EGCS (any
|
||||
version) to compile version 2.1 of GNU libc. See question 2.8 for details.
|
||||
|
||||
|
||||
1.3. When I try to compile glibc I get only error messages.
|
||||
|
|
@ -338,7 +338,7 @@ to the root of the 2.2 tree and do `make include/linux/version.h'.
|
|||
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.
|
||||
|
||||
|
||||
1.10. When I run `nm -u libc.so' on the produced library I still
|
||||
|
|
@ -729,8 +729,7 @@ 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.
|
||||
libraries from doing it. You must therefore compile glibc 2.1 with EGCS.
|
||||
Again, it doesn't matter what compiler you use for your programs.
|
||||
|
||||
|
||||
|
|
|
|||
13
FAQ.in
13
FAQ.in
|
|
@ -60,11 +60,11 @@ 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.3 and 1.1) and GNU CC (2.8.1) should work with the GNU C library
|
||||
(for powerpc see ?powerpc; for ARM see ?arm).
|
||||
egcs (1.0.3 and 1.1.1) should work with the GNU C library (for powerpc see
|
||||
?powerpc; for ARM see ?arm).
|
||||
|
||||
{ZW} You may have problems if you try to mix code compiled with
|
||||
EGCS and with GCC 2.8.1. See ?exception for details.
|
||||
{ZW} Due to problems with C++ exception handling, you must use EGCS (any
|
||||
version) to compile version 2.1 of GNU libc. See ?exception for details.
|
||||
|
||||
?? When I try to compile glibc I get only error messages.
|
||||
What's wrong?
|
||||
|
|
@ -188,7 +188,7 @@ to the root of the 2.2 tree and do `make include/linux/version.h'.
|
|||
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.
|
||||
|
||||
?? When I run `nm -u libc.so' on the produced library I still
|
||||
find unresolved symbols. Can this be ok?
|
||||
|
|
@ -562,8 +562,7 @@ 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.
|
||||
libraries from doing it. You must therefore compile glibc 2.1 with EGCS.
|
||||
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
|
||||
|
|
|
|||
48
INSTALL
48
INSTALL
|
|
@ -249,12 +249,13 @@ build the GNU C library:
|
|||
* EGCS 1.1.1, 1.1 or 1.0.3
|
||||
|
||||
The GNU C library can only be compiled with the GNU C compiler
|
||||
family. We recommend EGCS 1.0.3 or higher. GCC 2.8.1 and older
|
||||
versions of EGCS may have problems, particularly on non-Intel
|
||||
architectures. GCC 2.7.x has catastrophic bugs and cannot be used
|
||||
at all. (You can use GCC 2.7.x to compile programs that use GNU
|
||||
libc, but you may have problems, particularly with the math
|
||||
functions.)
|
||||
family. As of the 2.1 release, EGCS 1.0.3 or higher is required.
|
||||
GCC 2.8.1 cannot be used due to an incompatible implementation of
|
||||
some internal compiler support routines; see the FAQ for details.
|
||||
GCC 2.7.x is simply too buggy. You can use whatever compiler you
|
||||
like to compile programs that use GNU libc, but be aware that both
|
||||
GCC 2.7 and 2.8 have bugs in their floating-point support that may
|
||||
be triggered by the math library.
|
||||
|
||||
On Alpha machines you need at least EGCS 1.1.1. Earlier versions
|
||||
don't work reliably.
|
||||
|
|
@ -262,7 +263,7 @@ build the GNU C library:
|
|||
For PPC you might need some patches even on top of the last EGCS
|
||||
version. See the FAQ.
|
||||
|
||||
* GNU `binutils' 2.9.1, or 2.9.1.0.16
|
||||
* GNU `binutils' 2.9.1, 2.9.1.0.16, or later 2.9.1.0.x release
|
||||
|
||||
You must use GNU binutils (as and ld) if you want to build a shared
|
||||
library. Even if you don't, we recommend you use them anyway. No
|
||||
|
|
@ -270,9 +271,10 @@ build the GNU C library:
|
|||
|
||||
The quality of binutils releases has varied a bit recently. The
|
||||
bugs are in obscure features, but glibc uses quite a few of those.
|
||||
2.9.1 and 2.9.1.0.16 are known to work. Versions after 2.8.1.0.23
|
||||
may or may not work. Older versions definitely don't. 2.9.1.0.16
|
||||
is required on some platforms, like PPC and Arm.
|
||||
2.9.1, 2.9.1.0.16, and later 2.9.1.0.x releases are known to
|
||||
work. Versions after 2.8.1.0.23 may or may not work. Older
|
||||
versions definitely don't. 2.9.1.0.16 or higher is required on
|
||||
some platforms, like PPC and Arm.
|
||||
|
||||
For PPC you might need some patches even on top of the last
|
||||
binutils version. See the FAQ.
|
||||
|
|
@ -298,7 +300,7 @@ build the GNU C library:
|
|||
|
||||
If you change any of the `configure.in' files you will also need
|
||||
|
||||
* GNU `autoconf' 2.12
|
||||
* GNU `autoconf' 2.12 or higher
|
||||
|
||||
and if you change any of the message translation files you will need
|
||||
|
||||
|
|
@ -367,19 +369,19 @@ Specific advice for Linux systems
|
|||
=================================
|
||||
|
||||
If you are installing GNU libc on a Linux system, you need to have
|
||||
the header files from a development kernel around for reference. You
|
||||
do not need to use the development kernel, just have its headers where
|
||||
glibc can get at them. The easiest way to do this is to unpack a
|
||||
development kernel in a directory such as `/usr/src/linux-dev'. In that
|
||||
directory, run `make config' and accept all the defaults. Then
|
||||
configure glibc with the option
|
||||
`--with-headers=/usr/src/linux-dev/include'. Use the latest
|
||||
development kernel you can get your hands on.
|
||||
the header files from a 2.2 kernel around for reference. You do not
|
||||
need to use the 2.2 kernel, just have its headers where glibc can get
|
||||
at them. The easiest way to do this is to unpack it in a directory
|
||||
such as `/usr/src/linux-2.2.1'. In that directory, run `make config'
|
||||
and accept all the defaults. Then run `make include/linux/version.h'.
|
||||
Finally, configure glibc with the option
|
||||
`--with-headers=/usr/src/linux-2.2.1/include'. Use the most recent
|
||||
kernel you can get your hands on.
|
||||
|
||||
An alternate tactic is to unpack the development kernel and run
|
||||
`make config' as above. Then rename or delete `/usr/include', create a
|
||||
new `/usr/include', and make the usual symbolic links of
|
||||
`/usr/include/linux' and `/usr/include/asm' into the development kernel
|
||||
An alternate tactic is to unpack the 2.2 kernel and run `make
|
||||
config' as above. Then rename or delete `/usr/include', create a new
|
||||
`/usr/include', and make the usual symbolic links of
|
||||
`/usr/include/linux' and `/usr/include/asm' into the 2.2 kernel
|
||||
sources. You can then configure glibc with no special options. This
|
||||
tactic is recommended if you are upgrading from libc5, since you need
|
||||
to get rid of the old header files anyway.
|
||||
|
|
|
|||
|
|
@ -279,11 +279,12 @@ Version 3.76.1 seems OK but some people have reported problems.
|
|||
EGCS 1.1.1, 1.1 or 1.0.3
|
||||
|
||||
The GNU C library can only be compiled with the GNU C compiler family.
|
||||
We recommend EGCS 1.0.3 or higher. GCC 2.8.1 and older versions of EGCS
|
||||
may have problems, particularly on non-Intel architectures. GCC 2.7.x
|
||||
has catastrophic bugs and cannot be used at all. (You can use GCC 2.7.x
|
||||
to compile programs that use GNU libc, but you may have problems,
|
||||
particularly with the math functions.)
|
||||
As of the 2.1 release, EGCS 1.0.3 or higher is required. GCC 2.8.1 cannot
|
||||
be used due to an incompatible implementation of some internal compiler
|
||||
support routines; see the FAQ for details. GCC 2.7.x is simply too
|
||||
buggy. You can use whatever compiler you like to compile programs that
|
||||
use GNU libc, but be aware that both GCC 2.7 and 2.8 have bugs in their
|
||||
floating-point support that may be triggered by the math library.
|
||||
|
||||
On Alpha machines you need at least EGCS 1.1.1. Earlier versions don't
|
||||
work reliably.
|
||||
|
|
@ -292,17 +293,17 @@ For PPC you might need some patches even on top of the last EGCS version.
|
|||
See the FAQ.
|
||||
|
||||
@item
|
||||
GNU @code{binutils} 2.9.1, or 2.9.1.0.16
|
||||
GNU @code{binutils} 2.9.1, 2.9.1.0.16, or later 2.9.1.0.x release
|
||||
|
||||
You must use GNU binutils (as and ld) if you want to build a shared
|
||||
library. Even if you don't, we recommend you use them anyway. No one
|
||||
has tested compilation with non-GNU binutils in a long time.
|
||||
|
||||
The quality of binutils releases has varied a bit recently. The bugs
|
||||
are in obscure features, but glibc uses quite a few of those.
|
||||
2.9.1 and 2.9.1.0.16 are known to work. Versions after
|
||||
2.8.1.0.23 may or may not work. Older versions definitely don't.
|
||||
2.9.1.0.16 is required on some platforms, like PPC and Arm.
|
||||
are in obscure features, but glibc uses quite a few of those. 2.9.1,
|
||||
2.9.1.0.16, and later 2.9.1.0.x releases are known to work. Versions
|
||||
after 2.8.1.0.23 may or may not work. Older versions definitely don't.
|
||||
2.9.1.0.16 or higher is required on some platforms, like PPC and Arm.
|
||||
|
||||
For PPC you might need some patches even on top of the last binutils
|
||||
version. See the FAQ.
|
||||
|
|
@ -335,7 +336,7 @@ If you change any of the @file{configure.in} files you will also need
|
|||
|
||||
@itemize @bullet
|
||||
@item
|
||||
GNU @code{autoconf} 2.12
|
||||
GNU @code{autoconf} 2.12 or higher
|
||||
@end itemize
|
||||
|
||||
@noindent
|
||||
|
|
@ -417,23 +418,23 @@ switches via @var{CFLAGS}.
|
|||
@cindex upgrading from libc5
|
||||
@cindex kernel header files
|
||||
|
||||
If you are installing GNU libc on a Linux system, you need to have the
|
||||
header files from a development kernel around for reference. You do not
|
||||
need to use the development kernel, just have its headers where glibc
|
||||
can get at them. The easiest way to do this is to unpack a development
|
||||
kernel in a directory such as @file{/usr/src/linux-dev}. In that
|
||||
directory, run @samp{make config} and accept all the defaults. Then
|
||||
configure glibc with the option
|
||||
@samp{--with-headers=/usr/src/linux-dev/include}. Use the latest
|
||||
development kernel you can get your hands on.
|
||||
If you are installing GNU libc on a Linux system, you need to have
|
||||
the header files from a 2.2 kernel around for reference. You do not
|
||||
need to use the 2.2 kernel, just have its headers where glibc can get
|
||||
at them. The easiest way to do this is to unpack it in a directory
|
||||
such as @file{/usr/src/linux-2.2.1}. In that directory, run
|
||||
@samp{make config} and accept all the defaults. Then run @samp{make
|
||||
include/linux/version.h}. Finally, configure glibc with the option
|
||||
@samp{--with-headers=/usr/src/linux-2.2.1/include}. Use the most recent
|
||||
kernel you can get your hands on.
|
||||
|
||||
An alternate tactic is to unpack the development kernel and run
|
||||
@samp{make config} as above. Then rename or delete @file{/usr/include},
|
||||
create a new @file{/usr/include}, and make the usual symbolic links of
|
||||
@file{/usr/include/linux} and @file{/usr/include/asm} into the
|
||||
development kernel sources. You can then configure glibc with no
|
||||
special options. This tactic is recommended if you are upgrading from
|
||||
libc5, since you need to get rid of the old header files anyway.
|
||||
An alternate tactic is to unpack the 2.2 kernel and run @samp{make
|
||||
config} as above. Then rename or delete @file{/usr/include}, create
|
||||
a new @file{/usr/include}, and make the usual symbolic links of
|
||||
@file{/usr/include/linux} and @file{/usr/include/asm} into the 2.2
|
||||
kernel sources. You can then configure glibc with no special options.
|
||||
This tactic is recommended if you are upgrading from libc5, since you
|
||||
need to get rid of the old header files anyway.
|
||||
|
||||
Note that @file{/usr/include/net} and @file{/usr/include/scsi} should
|
||||
@strong{not} be symlinks into the kernel sources. GNU libc provides its
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
/* Function to parse a `long long int' from text.
|
||||
Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
|
||||
Copyright (C) 1995, 1996, 1997, 1999 Free Software Foundation, Inc.
|
||||
This file is part of the GNU C Library.
|
||||
|
||||
The GNU C Library is free software; you can redistribute it and/or
|
||||
|
|
@ -21,4 +21,5 @@
|
|||
|
||||
#include <strtol.c>
|
||||
|
||||
strong_alias (__strtoll_internal, __strtoq_internal)
|
||||
weak_alias (strtoll, strtoq)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
/* Function to parse an `unsigned long long int' from text.
|
||||
Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
|
||||
Copyright (C) 1995, 1996, 1997, 1999 Free Software Foundation, Inc.
|
||||
This file is part of the GNU C Library.
|
||||
|
||||
The GNU C Library is free software; you can redistribute it and/or
|
||||
|
|
@ -21,4 +21,5 @@
|
|||
|
||||
#include <strtoul.c>
|
||||
|
||||
strong_alias (__strtoull_internal, __strtouq_internal)
|
||||
weak_alias (strtoull, strtouq)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
/* Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc.
|
||||
/* Copyright (C) 1996, 1997, 1998, 1999 Free Software Foundation, Inc.
|
||||
This file is part of the GNU C Library.
|
||||
Contributed by Ulrich Drepper <drepper@gnu.ai.mit.edu>, 1996.
|
||||
Contributed by Ulrich Drepper <drepper@gnu.org>, 1996.
|
||||
|
||||
The GNU C Library is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU Library General Public License as
|
||||
|
|
@ -80,7 +80,7 @@ __mbrtowc (wchar_t *pwc, const char *s, size_t n, mbstate_t *ps)
|
|||
if (status == GCONV_OK || status == GCONV_EMPTY_INPUT
|
||||
|| status == GCONV_FULL_OUTPUT)
|
||||
{
|
||||
if (data.outbuf != outbuf && *(wchar_t *)data.outbuf == L'\0')
|
||||
if (data.outbuf != outbuf && *(wchar_t *)outbuf == L'\0')
|
||||
{
|
||||
/* The converted character is the NUL character. */
|
||||
assert (__mbsinit (data.statep));
|
||||
|
|
|
|||
Loading…
Reference in a new issue