Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
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>.
  • Loading branch information
Ulrich Drepper committed Feb 4, 1999
1 parent 05c83ef commit b8f558b
Show file tree
Hide file tree
Showing 8 changed files with 82 additions and 71 deletions.
8 changes: 8 additions & 0 deletions ChangeLog
@@ -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.
Expand Down
13 changes: 6 additions & 7 deletions FAQ
Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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.


Expand Down
13 changes: 6 additions & 7 deletions FAQ.in
Expand Up @@ -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?
Expand Down Expand Up @@ -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?
Expand Down Expand Up @@ -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
Expand Down
50 changes: 26 additions & 24 deletions INSTALL
Expand Up @@ -249,30 +249,32 @@ 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.

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
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.
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.
Expand All @@ -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

Expand Down Expand Up @@ -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.

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
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 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.
Expand Down
57 changes: 29 additions & 28 deletions manual/install.texi
Expand Up @@ -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.
Expand All @@ -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.
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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.

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.
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 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
Expand Down
3 changes: 2 additions & 1 deletion stdlib/strtoll.c
@@ -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
Expand All @@ -21,4 +21,5 @@

#include <strtol.c>

strong_alias (__strtoll_internal, __strtoq_internal)
weak_alias (strtoll, strtoq)
3 changes: 2 additions & 1 deletion stdlib/strtoull.c
@@ -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
Expand All @@ -21,4 +21,5 @@

#include <strtoul.c>

strong_alias (__strtoull_internal, __strtouq_internal)
weak_alias (strtoull, strtouq)
6 changes: 3 additions & 3 deletions wcsmbs/mbrtowc.c
@@ -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
Expand Down Expand Up @@ -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));
Expand Down

0 comments on commit b8f558b

Please sign in to comment.