This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: [v3] default to --disable-long-long, ctype fixes
- To: george at moberg dot com
- Subject: Re: [v3] default to --disable-long-long, ctype fixes
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- Date: 20 Dec 2000 20:19:11 +0100
- Cc: libstdc++ at gcc dot gnu dot org, bkoz at redhat dot com
- Organization: CodeSourcery, LLC
- References: <3A40FFED.93F8D5AE@moberg.com>
george@moberg.com writes:
| Please reconsider this. Would it be possible to put something in one of
| the libstdc++ headers like this:
|
| #ifdef _STDLIB_H
| #ifndef _GNU_SOURCE
| #error "Must add -D_GNU_SOURCE, or suitable system-dependent macro, to
| compile this program."
| #endif
| #endif
???
The World is not GNU Based.
| Turning off --enable-long-long is a really serious hardship for those
| who need it on. It means we have to recompile libstdc++-v3, right? Or
| since the compiler's now merged in, we would have to recompile both,
| right? I would seriously prefer to use the binaries as shipped with the
| distribution(s), rather than having to recompile all this.
Can you elaborate on this? As far as I can tell we do not distribute
v3 binaries; and with the last snapshot it appears that V3 is being
thighly coupled with 2.97 or higher; so if you consider using current
CVS V3 then you have to recompile it anyway.
I understand that it would be lovely nice to use V3 with the
already installed compiler without recompiling anything but that is
requiring more investment that it worths.
| Also, it introduces binary incompatibilities for anyone who builds a
| program with --enable-long-long, if I'm not mistaken.
--enable-long-long is not the only place we're introducing binary
incompatibility with current CVS. Please, don't forget that current
CVS is not yet released and before we make an official release
(presumably as part of GCC-3.0) we'll introduce even more binary
incompatibilities. Current CVS is experimental and one should not
forget that when linking program against it.
| I'd much rather have the slight weirdness of a #error in a header file
| than the binary incompatibilities and recompilation hardship of dropping
| long long support.
|
| After all, long long will be required eventually.
Probably, but by the time it becomes officially standard we'll have
time to address more pressing issues. Don't forget that long long is
an extension; as such it should not consume more resource than
implementing standard features.
I'm more interested in investing effort in makeing standard features
work. In other words, standard features first, extensions latter.
-- Gaby
CodeSourcery, LLC http://www.codesourcery.com