> If you have questions (or better yet, patches *grin*), by all means include
> the list. However, if you do, I'd recommend /not/ cc'ing @bugs.debian.org,
> because those auto-acks are awfully annoying.
{Removing [EMAIL PROTECTED], adding [EMAIL PROTECTED]
See http://bugs.debian.org/126703 for past discussion}
> Here's a super-short summary of _GNU_SOURCE. [...] We need the
> symbol to be defined before including any header which could
> possibly include a glibc header, otherwise certain C++ programs will
> simply fail out of the box.
I don't believe that this is true.
> The C++ rules are much stricter than in C (duh), and in order to get
> standard-conforming semantics out of glibc 2.2, we had to feed it
> _GNU_SOURCE.
My theory: The only reason to define this is to re-export symbols from
the <cfoo> headers, inside std::.
> The change was initially made here:
>
> http://gcc.gnu.org/ml/libstdc++/2000-12/msg00215.html
That is a specific case of libstdc++ wanting to re-export a symbol in
std::, namely std::lldiv_t. The code in question reads
# if _GLIBCPP_HAVE_LLDIV_T
typedef lldiv_t _CPP_lldiv_t_capture;
# endif
Now, the problem is that _GLIBCPP_HAVE_LLDIV_T is always defined. I
propose that, on glibc, it is only defined if __USE_ISOC99 is also
defined. So c++config.h would not read
#define _GLIBCPP_HAVE_LLDIV_T 1
but would read
#ifdef __USE_ISOC99
#define _GLIBCPP_HAVE_LLDIV_T 1
#endif
Would that work (leaving alone the question of how to generate such a
c++config.h; this would clearly need to know that the library is
glibc).
>
> Somebody moved the _GNU_SOURCE definition into the compiler itself, for
> all platforms. Somebody else noticed and complained here:
>
> http://gcc.gnu.org/ml/gcc/2001-06/msg00108.html
>
> which started a huge thread, all instructive.
I've read all of this thread, and it seemed that nobody really knows
why this change was made. Jason remembered that it was because of the
#include <stdlib.h>
#include <iostream>
case.
> The end result was that _GNU_SOURCE is defined by the compiler, only
> in C++ mode, only for those platforms which use glibc, because
> otherwise code such as the example in the first message Just Won't
> Work.
That's because of a bug in libstdc++. It should not attempt to
reexport symbols that the C library does not offer.
> Yes, it's a mess for glibc-using platforms. Solutions welcome. :-)
I can't offer patches, but would you think a more selective strategy
for reexporting symbols would help? I think getting c++config.h right
would solve all of this: wrap any _GLIBCPP_HAVE define with the
appropriate __USE_ define, on glibc-using platforms.
Regards,
Martin
