This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: [RFA:] libstdc++-v3 patches to bootstrap on gnulibc1 andglibc2.0
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: [RFA:] libstdc++-v3 patches to bootstrap on gnulibc1 andglibc2.0
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- Date: Tue, 21 Nov 2000 22:39:47 -0500 (EST)
- cc: gcc-patches at gcc dot gnu dot org, libstdc++ at sources dot redhat dot com, drepper at cygnus dot com
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
important.
brgds, H-P