This is the mail archive of the
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: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Wed, 20 Dec 2000 12:35:52 -0800 (PST)
- cc: libstdc++ at gcc dot gnu dot org, gdr at codesourcery dot com, drepper at cygnus dot com
Right. Sorry if I was so abrupt before.
Here are the gory details for linux:
This is basically a "C" header issue, as far as I'm concerned. The only
way to get definitions like 'lldiv_t' out of stdlib.h is to pass
_GNU_SOURCE. As this option is not passed by default, ISO-C9X features
are turned off when a user does something like "#include <stdlib.h>" and
then compiles like "g++ foo.cc"
That case has to work.
The problem comes in where libstdc++-v3 explicitly enables ISO-C99
features in config/os/gnu-linux/bits/os_defines.h -- this is used during
configure to probe and see what kind of ISO-C99 support is around: on
linux, as _GNU_SOURCE is explicitly defined, lldiv_t is found in
stdlib.h, so HAVE_LLDIV_T is defined. This makes sense. The problem is
when a user does something like
and compiles like "g++ foo.cc"
What happens: stdlib.h is parsed without ISO-C99 features, then cstdlib
is parsed, expecting ISO-C99 features from stdlib.h, including things like
lldiv_t. This is incorrect, and results in a compile-time failure. This is bad.
Other heades are also show similar symptoms.
Does this make it easier to understand why it's off by default? I agree,
it would be nice to have it on by default. However, I don't see how
that's possible, given the current state of C99 support in the "C" library.
Ulrich, feel free to correct me if I'm way off base.