Re: Bug#126703: g++-3.0: <stdio.h> defines _GNU_SOURCE with g++-3.0

["Martin v. Loewis" <martin at v dot loewis dot de>]

> 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 126703@bugs.debian.org, adding libstdc++@gcc.gnu.org.
 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