[RFA:] libstdc++-v3 patches to bootstrap on gnulibc1 andglibc2.0

Hans-Peter Nilsson hp@bitrange.com
Tue Nov 21 19:39:00 GMT 2000

On Tue, 21 Nov 2000, Benjamin Kosnik wrote:
> No, please don't install as is.
> Please enclose a unified ChangeLog, in the canonical GNU style as part of
> you patch.

Sure.  I'd like to point out that this patch was (mistakenly?) originally
sent to gcc-patches, where the "Date"-line of ChangeLog entries is
commonly omitted for practical reasons since the date of commit is often
different than the date the patch is generated (I think; at least it's a
common habit).

>        * config/os/gnu-linux/bits/os_defines.h: Include <sys/types.h>.
>         If not glibc 2.1 or higher, include <gnu/types.h> and define
>         __off64_t as __loff_t.
> Please don't include sys/types.h here, use features.h, which should
> work with older glibc's as well. If older glibc needs this include,
> then macro-guard it and include only in that case.

Do you mean macro-guard #include <features.h>?  If so, with *what* macro?

As I wrote, there are (were?) cases where no system header file was
included before os_defines.h, so there's no glibc-macro to check.  There
could presumably be command-line macros added by configury, but there's no
working framework for that.  I tried adding *-*-linux*libc1 bits to
configure.target setting glibcpp_cflags to -DUSE_GNULIBC_1, but the
presumed CFLAGS-like macro wasn't used(!).  (And specific configure tests
to catch glibc 2.0 would be needed in addition to that.)

>         (__underflow, __overflow): Remove __THROW qualifier in declaration.
> this part is confused. The comment above this change says:
> ! /* The absence of __THROW specifiers on __underflow and __overflow is
> !    because those are declared in system headers on some systems without
> !    any throw-specifier.  Those functions are not called from C++ within
> !    libio anyway, so a throw specifier is redundant.  */
> This isn't for 'some systems' this is for an old glibc. Can you be
> more specific? What other system headers are you talking about?

Right, I could have been clearer and shouldn't have generalized.  There
was declaration mismatch in that the system definition for __P in libc
5.3.12 and glibc 2.0 lacked __THROW and so the declarations for
__underflow and __overflow which for some reason were in
/usr/include/stdio.h for both versions were then naked and throw-less,
mismatching the V3/libio.h ones.  Producing this compile-error:

[long commandline invoking newly-compiled g++] -o .libs/complex.o
/home/hp/tmp/gccwrite/gcc/include/stdio.h:224: declaration of `int 
   __underflow(_IO_FILE*)' throws different exceptions
/home/hp/egcs/cvs_write/egcs/libstdc++-v3/libio/libio.h:410: than previous 
   declaration `int __underflow(_IO_FILE*) throw ()'
/home/hp/tmp/gccwrite/gcc/include/stdio.h:225: declaration of `int 
   __overflow(_IO_FILE*, int)' throws different exceptions
/home/hp/egcs/cvs_write/egcs/libstdc++-v3/libio/libio.h:412: than previous 
   declaration `int __overflow(_IO_FILE*, int) throw ()'

This declaration from /usr/include/stdio.h:
  extern int __underflow __P((struct _IO_FILE*));
was seen with a __P that did not include __THROW, and thus mismatching
this one from libstdc++-v3/libio:
  extern int __underflow (_IO_FILE *) __THROW;

Only these two colliding function prototypes were in stdio.h.  Thus no
others needed tweaking.

> It
> might make sense to just change the defines for __THROW for this
> particular case, and not modify the signatures by removing the __THROW
> macro.

That should work.  Should I do that instead?  I'm testing a change in this
direction in case, defining __THROW to be empty in os_defines.h for those
old glibc versions.  Will send patch tomorrow after testing.

> We're trying to keep sync with net glibc/libio now. Please keep that in mind.

I see.  I thought I saw an outdated libioP.h (missing bits to find
libc-lock.h properly, which was there in gcc-toplevel/libio) and though it
was on its way out of the libstdc++-v3 configuration and so this was not

brgds, H-P

More information about the Libstdc++ mailing list