G++ defining _GNU_SOURCE

G++ defining _GNU_SOURCE

[David Edelsohn]

	Why does GCC 3 now uniformly define _GNU_SOURCE in
cp/lang-specs.h?  This macro definition does not depend on the platform
using the GNU C Library.  It was not defined in gcc-2.95.

	Is this defined because of libstdc++-v3?

Thanks, David

Re: G++ defining _GNU_SOURCE

[Phil Edwards]

On Mon, Jun 04, 2001 at 01:08:42PM -0400, David Edelsohn wrote:
> 
> 	Is this defined because of libstdc++-v3?

Shouldn't be.  The libstdc++-v3/config/os and CPLSUPLUS_CPP_DEFINES should
be taking care of that requirement where it's needed.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: G++ defining _GNU_SOURCE

[David Edelsohn]

	We still have no answer to the question why _GNU_SOURCE is defined
in cp/lang-specs.h.  Its presence changes the behavior of some Free
Software header files.  This definition was not present in gcc-2.95.  This
macro is not defined for the GNU C Compiler, only the GNU C++ Compiler.

David

Re: G++ defining _GNU_SOURCE

[Phil Edwards]

On Tue, Jun 05, 2001 at 04:47:28PM -0400, David Edelsohn wrote:
> 	We still have no answer to the question why _GNU_SOURCE is defined
> in cp/lang-specs.h.  Its presence changes the behavior of some Free
> Software header files.  This definition was not present in gcc-2.95.  This
> macro is not defined for the GNU C Compiler, only the GNU C++ Compiler.

cvs annotate is your friend:

    2001-01-19  Jason Merrill  <jason@redhat.com>

        * init.c (build_delete): Always call convert_force to strip cv-quals.

        * decl2.c (flag_new_abi): Depend on ENABLE_NEW_GXX_ABI.
        * lang-specs.h: Default ABI depends on ENABLE_NEW_GXX_ABI.
        * g++spec.c: Don't look at ENABLE_NEW_GXX_ABI.


Jason?  Can we remove the _GNU_SOURCE part of this change?  libstdc++-v3
doesn't need it here.  Well, it /shouldn't/, if it does then it needs to
be moved into os_defines.h and CXX_CPP_DEFINES.

Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: G++ defining _GNU_SOURCE

[Mark Mitchell]

>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:

    David> 	We still have no answer to the question why
    David> _GNU_SOURCE is defined in cp/lang-specs.h. 

I suggest CVS archaeology to find out who checked in and when and what
ChangeLog entry (even if not mentioning this change) went in at the
same time.  That might allow us to reconstruct why the change was
made.

I agree that it is bogus on systems in general, and maybe even on
GNU/Linux.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: G++ defining _GNU_SOURCE

[Nathan Sidwell]

Phil Edwards wrote:
> 
> On Tue, Jun 05, 2001 at 04:47:28PM -0400, David Edelsohn wrote:
> >       We still have no answer to the question why _GNU_SOURCE is defined
> > in cp/lang-specs.h.  Its presence changes the behavior of some Free
> > Software header files.  This definition was not present in gcc-2.95.  This
> > macro is not defined for the GNU C Compiler, only the GNU C++ Compiler.

Here is my recollection of the problem.

On linux (at least) _GNU_SOURCE needs to be #defined from the start because the
user can write a program like
	#include <stdio.h>  // non-libstdc++ header
	#include <iostream> // libstdc++ header

Both these includes wind up #including the idempotent /usr/include/features.h
which uses _GNU_SOURCE to turn on various bit'n'bobs that libstdc++
needs/expects. Now the above snippet will include features via stdio.h,
_before_ any libstdc++-v3 header has a chance to set _GNU_SOURCE. When
iostream is included it is too late.

I think the symptoms are more severe when -pedantic -ansi is used.

I remember preparing a patch to libstdc++'s config/os/gnu-linux/os_defines.h
to at least detect this issue, but Jason fixed it the way he did first.

Hope that helps.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: G++ defining _GNU_SOURCE

[Jason Merrill]

>>>>> "Phil" == Phil Edwards <pedwards@disaster.jaj.com> writes:

> On Tue, Jun 05, 2001 at 04:47:28PM -0400, David Edelsohn wrote:
>> We still have no answer to the question why _GNU_SOURCE is defined
>> in cp/lang-specs.h.  Its presence changes the behavior of some Free
>> Software header files.  This definition was not present in gcc-2.95.  This
>> macro is not defined for the GNU C Compiler, only the GNU C++ Compiler.

> cvs annotate is your friend:

>     2001-01-19  Jason Merrill  <jason@redhat.com>

>         * init.c (build_delete): Always call convert_force to strip cv-quals.

>         * decl2.c (flag_new_abi): Depend on ENABLE_NEW_GXX_ABI.
>         * lang-specs.h: Default ABI depends on ENABLE_NEW_GXX_ABI.
>         * g++spec.c: Don't look at ENABLE_NEW_GXX_ABI.

> Jason?  Can we remove the _GNU_SOURCE part of this change?

Yes, please.  I think it was an accident.

Jason

Re: G++ defining _GNU_SOURCE

[Mark Mitchell]

>>>>> "Nathan" == Nathan Sidwell <nathan@codesourcery.com> writes:

    Nathan> Both these includes wind up #including the idempotent
    Nathan> /usr/include/features.h which uses _GNU_SOURCE to turn on
    Nathan> various bit'n'bobs that libstdc++ needs/expects. Now the

That makes sense.  So, really this should be in CPP_CPLUSPLUS_SPECS on
all GNU/Linux systems -- and other systems that use GLIBC -- but
probably not elsewhere.  And, as we all know, the library needs to be
tweaked to not require these extensions when the user hasn't defined
_GNU_SOURCE so that we don't have to do this at all.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: G++ defining _GNU_SOURCE

[Fergus Henderson]

On 06-Jun-2001, Nathan Sidwell <nathan@codesourcery.com> wrote:
> 
> Here is my recollection of the problem.
> 
> On linux (at least) _GNU_SOURCE needs to be #defined from the start because the
> user can write a program like
> 	#include <stdio.h>  // non-libstdc++ header
> 	#include <iostream> // libstdc++ header
> 
> Both these includes wind up #including the idempotent /usr/include/features.h
> which uses _GNU_SOURCE to turn on various bit'n'bobs that libstdc++
> needs/expects.

Defining _GNU_SOURCE even when -ansi is specified is a bug, isn't it?
It will break standard-conforming programs that happen to use the
same identifiers that _GNU_SOURCE enables.  If libstdc++ requires that
_GNU_SOURCE be defined, then that is a bug in libstdc++, and ought to
be fixed.

I haven't looked at the libstdc++ source, so I could be way off here, but
I think it could perhaps be fixed, at the cost of efficiency, by making all
the libstdc++ usages of non-standard identifiers that might invade the
user's namespaces go via non-inline wrapper functions;
these wrapper functions would have names that don't invade any of the
user's namespaces, and would be defined in libstdc++ in .cc files.
(It's OK to define _GNU_SOURCE when compiling the .cc files in libstdc++;
defining _GNU_SOURCE when compiling the user's .cc files is what causes
problems.)

Alternatively, glibc could be modified to define alternative versions
of all of these identifiers that start with `__', and libstdc++ could use
those versions.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: G++ defining _GNU_SOURCE

[Joseph S. Myers]

On Thu, 7 Jun 2001, Fergus Henderson wrote:

> Alternatively, glibc could be modified to define alternative versions
> of all of these identifiers that start with `__', and libstdc++ could use
> those versions.

Glibc should already do so - since users must be able to define their own
functions with names not included in the ISO C standard, so glibc needs to
define the __ names to use internally and make the non-__ names weak
aliases.  *But* most of the __ names are not exported from glibc, since
they are only intended for internal use, and the public glibc headers
don't declare most of them either.  Making glibc work better with C++ is
on the glibc 2.3 TODO list <URL: http://www.cygnus.com/~drepper/TODO.html >.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: G++ defining _GNU_SOURCE

[David Edelsohn]

	The only references to _GNU_SOURCE in V3 itself are in libio and
src/gen-num-limits.cc.  The macro is tested by configure.

David

Re: G++ defining _GNU_SOURCE

[Mark Mitchell]

>>>>> "Nathan" == Nathan Sidwell <nathan@codesourcery.com> writes:

    Nathan> Phil Edwards wrote:
    >>  On Tue, Jun 05, 2001 at 04:47:28PM -0400, David Edelsohn
    >> wrote: > We still have no answer to the question why
    >> _GNU_SOURCE is defined > in cp/lang-specs.h.  Its presence
    >> changes the behavior of some Free > Software header files.
    >> This definition was not present in gcc-2.95.  This > macro is
    >> not defined for the GNU C Compiler, only the GNU C++ Compiler.

    Nathan> Here is my recollection of the problem.

Right.  I think we need to put this in CPP_CPLUSPLUS_PREDEFINES so
that it only happens on the platforms where we really need it, if it's
causing trouble on AIX somehow.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: G++ defining _GNU_SOURCE

[Mark Mitchell]

>>>>> "Fergus" == Fergus Henderson <fjh@cs.mu.oz.au> writes:
 
   Fergus> Defining _GNU_SOURCE even when -ansi is specified is a
   Fergus> bug, isn't it? 

Yes.  All of the messing about with os_defines.h and
CPP_CPLUSPLUS_PREDEFINES is entirely broken in the long run.

It is a short-term hack to allow V3 to work with GCC 3.0.  The task of
fixing the library so that these things are not needed should be
extremely high-priority for the V3 team in GCC 3.1.  There is
certainly no more important missing feature, other than the C header
issues.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: G++ defining _GNU_SOURCE

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> Right.  I think we need to put this in CPP_CPLUSPLUS_PREDEFINES so
Mark> that it only happens on the platforms where we really need it, if it's
Mark> causing trouble on AIX somehow.

	This is not an AIX problem.  This is a problem for any non-glibc2
target. 

David

Re: G++ defining _GNU_SOURCE

[Mark Mitchell]

>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:

    David> 	This is not an AIX problem.  This is a problem for any
    David> non-glibc2 target.

You mean it's not *only* an AIX problem.

Well, this is even a problem for a GNU/Linux target, too, really, in a
way.

This is a fundamentally missing feature in the library -- the V3
library forces you to pick a certain system library interface, instead
of affording you the usual flexibility.

Until it gets added, all we can do is try to mitigate the damage.

Fortunately, it looks like Phil will come up with something.

Phil, I ould stick with linux.h.  Just add _GNU_SOURCE to add targets
that include linux.h and define their own C++ predefines so that we
can be sure that they get it too.  That will allow us to remove it
from lang-specs.h.  It you feel like doing gnu.h too, that's fine --
but in practice very few people are using the Hurd.  GLIBC2 is used on
GNU/Linux and not very many other places, AFAIK.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: G++ defining _GNU_SOURCE

[Phil Edwards]

On Thu, Jun 07, 2001 at 03:38:25PM -0700, Mark Mitchell wrote:
> This is a fundamentally missing feature in the library -- the V3
> library forces you to pick a certain system library interface, instead
> of affording you the usual flexibility.

Enh.  Nobody seemed interested in anything better at the time.


> Phil, I ould stick with linux.h.  Just add _GNU_SOURCE to add targets
> that include linux.h and define their own C++ predefines so that we
> can be sure that they get it too.

The only question is, does PA/Linux need it?  If not, then the initial
patch I posted is all that's needed, I believe.

pa-linux.h #undefs the predefines for a reson, I expect...?

pa.h defines the predefs but clearly shouldn't get linux-specific stuff.

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: G++ defining _GNU_SOURCE

[Mark Mitchell]

>>>>> "Phil" == Phil Edwards <pedwards@disaster.jaj.com> writes:

    Phil> Enh.  Nobody seemed interested in anything better at the
    Phil> time.

:-)  Yes, problems have a way of becoming severe after other, even
more severe, problems are fixed.

    >> Phil, I ould stick with linux.h.  Just add _GNU_SOURCE to add
    >> targets that include linux.h and define their own C++
    >> predefines so that we can be sure that they get it too.

    Phil> The only question is, does PA/Linux need it?  If not, then
    Phil> the initial patch I posted is all that's needed, I believe.

    Phil> pa-linux.h #undefs the predefines for a reson, I expect...?

It's trying to undo the pa.h version.  So, it should #undef (to avoid
the pa.h version), and then redefine to have the linux.h version.
Consider the patch pre-approved, along with your earlier change.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: G++ defining _GNU_SOURCE

[Phil Edwards]

On Thu, Jun 07, 2001 at 03:59:22PM -0700, Mark Mitchell wrote:
> 
>     Phil> pa-linux.h #undefs the predefines for a reson, I expect...?
> 
> It's trying to undo the pa.h version.  So, it should #undef (to avoid
> the pa.h version), and then redefine to have the linux.h version.
> Consider the patch pre-approved, along with your earlier change.

Lemme just make absolutely paranoid-ly certain of this...

The tm_file order in config.gcc is

    pa/pa.h linux.h pa/pa-linux.h

So, pa.h defines it,
    linux.h doesn't define it (but would undef/redefine it after my patch),
    pa-linux.h undefines it,

and so pa-linux.h would then need to re-define it to the union of the pa.h
version and my one-line linux.h version?  And have to be maintained by hand?

This sounds like spaghetti code with teeth.  Please tell me I've got this
massively confused somehow.

(can't think of an easy way for linux.h to simply "prepend" -D_GNU_SOURCE
to a previously-defined possibly empty CPLUSPLUS_CPP_DEFINE, rather than
undef'ing it and fully redefining it.)


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: G++ defining _GNU_SOURCE

[Mark Mitchell]

>>>>> "Phil" == Phil Edwards <pedwards@disaster.jaj.com> writes:

    Phil> and so pa-linux.h would then need to re-define it to the
    Phil> union of the pa.h version and my one-line linux.h version?
    Phil> And have to be maintained by hand?

Uh, no.  Actually, given that order, I think all mention of this would
just disappear from pa-linux.h.  The point is that pa-linux doesn't
want the main PA stuff -- but it does want the main GNU/Linux stuff.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: G++ defining _GNU_SOURCE

[Phil Edwards]

On Thu, Jun 07, 2001 at 04:30:35PM -0700, Mark Mitchell wrote:
> The point is that pa-linux doesn't
> want the main PA stuff -- but it does want the main GNU/Linux stuff.

Mmm.  Okay.  Dunno why that wasn't clear before.

This is what I'm checking in.


Index: cp/lang-specs.h
===================================================================
retrieving revision 1.43
diff -u -3 -r1.43 lang-specs.h
--- cp/lang-specs.h	2001/04/06 06:17:33	1.43
+++ cp/lang-specs.h	2001/06/06 22:33:36
@@ -35,13 +35,13 @@
   {"@c++",
    /* cc1plus has an integrated ISO C preprocessor.  We should invoke
       the external preprocessor if -save-temps is given.  */
-    "%{E|M|MM:cpp0 -lang-c++ -D_GNU_SOURCE %{!no-gcc:-D__GNUG__=%v1}\
+    "%{E|M|MM:cpp0 -lang-c++ %{!no-gcc:-D__GNUG__=%v1}\
        %{!Wno-deprecated:-D__DEPRECATED}\
        %{!fno-exceptions:-D__EXCEPTIONS}\
        %{!fno-new-abi:-D__GXX_ABI_VERSION=100}\
        %{ansi:-D__STRICT_ANSI__ -trigraphs -$} %(cpp_options)}\
      %{!E:%{!M:%{!MM:\
-       %{save-temps:cpp0 -lang-c++ -D_GNU_SOURCE \
+       %{save-temps:cpp0 -lang-c++ \
 		    %{!no-gcc:-D__GNUG__=%v1}\
        		    %{!Wno-deprecated:-D__DEPRECATED}\
 		    %{!fno-exceptions:-D__EXCEPTIONS}\
@@ -50,7 +50,7 @@
 		    %(cpp_options) %b.ii \n}\
       cc1plus %{save-temps:-fpreprocessed %b.ii}\
               %{!save-temps:%(cpp_options)\
-			    %{!no-gcc:-D__GNUG__=%v1} -D_GNU_SOURCE \
+			    %{!no-gcc:-D__GNUG__=%v1} \
        			    %{!Wno-deprecated:-D__DEPRECATED}\
 			    %{!fno-exceptions:-D__EXCEPTIONS}\
 			    %{!fno-new-abi:-D__GXX_ABI_VERSION=100}\
Index: config/linux.h
===================================================================
retrieving revision 1.12
diff -u -3 -r1.12 linux.h
--- config/linux.h	2001/04/16 18:30:34	1.12
+++ config/linux.h	2001/06/06 22:33:22
@@ -75,6 +75,13 @@
 #define CC1_SPEC "%{profile:-p}"
 #endif
 
+/* The GNU C++ standard library requires that these macros be
+   defined.  */
+#undef CPLUSPLUS_CPP_SPEC
+#define CPLUSPLUS_CPP_SPEC                      \
+  "-D_GNU_SOURCE                                \
+   %(cpp_cpu)"
+
 #ifndef USE_GNULIBC_1
 #undef DEFAULT_VTABLE_THUNKS
 #define DEFAULT_VTABLE_THUNKS 1
Index: config/pa/pa-linux.h
===================================================================
retrieving revision 1.5
diff -u -3 -r1.5 pa-linux.h
--- config/pa/pa-linux.h	2001/04/20 01:13:37	1.5
+++ config/pa/pa-linux.h	2001/06/07 23:45:23
@@ -27,8 +27,6 @@
 #undef CPP_PREDEFINES
 #define CPP_PREDEFINES "-D__ELF__ -Dunix -D__hppa__ -Dlinux -Asystem=unix -Asystem=posix -Acpu=hppa -Amachine=hppa -Amachine=bigendian"
 
-#undef CPLUSPLUS_CPP_SPEC
-
 #undef	LIB_SPEC
 #define LIB_SPEC "%{!p:%{!pg:-lc}}%{p:-lc_p}%{pg:-lc_p}"
 

Re: G++ defining _GNU_SOURCE

[Richard Henderson]

Which reminds me...



r~


        * config/alpha/linux.h (CPLUSPLUS_CPP_SPEC): New.
        (LIB_SPEC): Mirror config/linux.h version.

Index: linux.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/alpha/linux.h,v
retrieving revision 1.21.4.1
diff -c -p -d -r1.21.4.1 linux.h
*** linux.h	2001/05/13 07:10:07	1.21.4.1
--- linux.h	2001/06/09 00:35:59
*************** Boston, MA 02111-1307, USA.  */
*** 28,35 ****
  "-Dlinux -Dunix -Asystem=linux -D_LONGLONG -D__alpha__ " \
  SUB_CPP_PREDEFINES
  
  #undef LIB_SPEC
! #define LIB_SPEC "%{pg:-lgmon} %{pg:-lc_p} %{!pg:-lc}"
  
  /* Show that we need a GP when profiling.  */
  #undef TARGET_PROFILING_NEEDS_GP
--- 28,42 ----
  "-Dlinux -Dunix -Asystem=linux -D_LONGLONG -D__alpha__ " \
  SUB_CPP_PREDEFINES
  
+ /* The GNU C++ standard library requires that these macros be defined.  */
+ #undef CPLUSPLUS_CPP_SPEC
+ #define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE %(cpp_cpu)"
+ 
  #undef LIB_SPEC
! #define LIB_SPEC \
!   "%{shared: -lc} \
!    %{!shared: %{pthread:-lpthread} \
!               %{profile:-lc_p} %{!profile: -lc}}"
  
  /* Show that we need a GP when profiling.  */
  #undef TARGET_PROFILING_NEEDS_GP

Re: G++ defining _GNU_SOURCE

[Jason Merrill]

>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:

>         * config/alpha/linux.h (CPLUSPLUS_CPP_SPEC): New.

Won't the config/linux.h definition suffice?

Jason

Re: G++ defining _GNU_SOURCE

[Richard Henderson]

On Sun, Jun 10, 2001 at 12:58:09PM +0100, Jason Merrill wrote:
> Won't the config/linux.h definition suffice?

We don't include that file.


r~

Re: G++ defining _GNU_SOURCE

[Franz Sirl]

At 13:58 10.06.2001, Jason Merrill wrote:
> >>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:
>
> >         * config/alpha/linux.h (CPLUSPLUS_CPP_SPEC): New.
>
>Won't the config/linux.h definition suffice?

Nearly no linux platform uses this file since it's too x86 specific. 
Actually I believe not even most of the *_SPEC defines belong in there, 
they differ too much across all the linux targets.

On the patch itself, how can "-D_GNU_SOURCE %(cpp_cpu)" be correct? 
Shouldn't that be %(cpp)? At least on PPC I have to use %(cpp), because 
otherwise c++ won't get -D__BIG_ENDIAN__ (preventing compilation of 
libstdc++) etc. and things like -posix, -pthread, -fpic/-fPIC won't produce 
the proper defines _POSIX_SOURCE, _REENTRANT and __pic__/__PIC__.

Franz.

Re: G++ defining _GNU_SOURCE

[Phil Edwards]

On Mon, Jun 11, 2001 at 12:19:24PM +0200, Franz Sirl wrote:
> On the patch itself, how can "-D_GNU_SOURCE %(cpp_cpu)" be correct? 
> Shouldn't that be %(cpp)?

*shrug*  I copied the entry from AIX's config, and removed all the stuff that
was clearly AIX-specific.  Only these two remained.  If this is wrong for
one platform, it might be wrong for the other instances (including AIX) too.

Every time I try to figure out a pattern to the specs, my brain leaks out
my left ear.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: G++ defining _GNU_SOURCE

[Franz Sirl]

At 12:38 11.06.2001, Phil Edwards wrote:
>On Mon, Jun 11, 2001 at 12:19:24PM +0200, Franz Sirl wrote:
> > On the patch itself, how can "-D_GNU_SOURCE %(cpp_cpu)" be correct?
> > Shouldn't that be %(cpp)?
>
>*shrug*  I copied the entry from AIX's config, and removed all the stuff that
>was clearly AIX-specific.  Only these two remained.  If this is wrong for
>one platform, it might be wrong for the other instances (including AIX) too.

aix51.h has both CPP_SPEC and CPLUSPLUS_CPP_SPEC and if you look close you 
see most of the stuff between them is shared, except -ansi (makes no sense 
with C++) and -posix (probably because _ALL_SOURCE is a superset of 
_POSIX_SOURCE? David?). So, this means there are 2 possibilities to get the 
same cpp behaviour for C and C++:

1. define CPLUSCPLUS_CPP_SPEC as "-D_GNU_SOURCE " + CPP_SPEC. Am I right to 
assume that K&R doesn't support:

#define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE " CPP_SPEC

? Or is there a way to do this in K&R? Otherwise most of the stuff between 
CPP_SPEC and CPLUSPLUS_CPP_SPEC has to be shared (like aix51.h does) and 
this looks quite error prone to me.

2. #define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE %(cpp)"
AFAICT %(cpp) always expands to CPP_SPEC, contrary to %C which expands to 
either CPP_SPEC or the language specific spec (eg. CPLUSPLUS_CPP_SPEC)

Anyway, I don't see this belonging into config/linux.h, each linux target 
should handle this separately. IMHO all the *_SPEC definitions in 
config/linux.h should be only examples and no real definitions.

>Every time I try to figure out a pattern to the specs, my brain leaks out
>my left ear.

hehe, it took me a while too :-).

Franz.

Re: G++ defining _GNU_SOURCE

[Richard Henderson]

On Mon, Jun 11, 2001 at 12:19:24PM +0200, Franz Sirl wrote:
> On the patch itself, how can "-D_GNU_SOURCE %(cpp_cpu)" be correct? 
> Shouldn't that be %(cpp)?

I think you're right.


r~

Re: G++ defining _GNU_SOURCE

[Jason Merrill]

>>>>> "Franz" == Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

> At 13:58 10.06.2001, Jason Merrill wrote:
>> >>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:
>> 
>> >         * config/alpha/linux.h (CPLUSPLUS_CPP_SPEC): New.
>> 
>> Won't the config/linux.h definition suffice?

> Nearly no linux platform uses this file since it's too x86
> specific. Actually I believe not even most of the *_SPEC defines belong in
> there, they differ too much across all the linux targets.

Ah.  That seems like a bug, but I suppose not worth dealing with right now.

Jason

Re: G++ defining _GNU_SOURCE

[Franz Sirl]

On Monday 11 June 2001 19:06, Richard Henderson wrote:
> On Mon, Jun 11, 2001 at 12:19:24PM +0200, Franz Sirl wrote:
> > On the patch itself, how can "-D_GNU_SOURCE %(cpp_cpu)" be correct?
> > Shouldn't that be %(cpp)?
>
> I think you're right.

At least powerpc-linux-gnu now bootstraps again for me with the appended 
patch.

OK to commit to mainline and 3.0 branch?

Franz.

Re: G++ defining _GNU_SOURCE

[David Edelsohn]

	Looks good to me.

Thanks!
David

Re: G++ defining _GNU_SOURCE

[Richard Henderson]

On Mon, Jun 11, 2001 at 08:05:31PM +0200, Franz Sirl wrote:
> +#undef CPLUSPLUS_CPP_SPEC
> +#define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE %(cpp)"

Ok everywhere.


r~

Re: G++ defining _GNU_SOURCE

[Richard Henderson]

> > On the patch itself, how can "-D_GNU_SOURCE %(cpp_cpu)" be correct? 
> > Shouldn't that be %(cpp)?

To that end, I've applied the following.


r~


        * config/linux.h (CPLUSPLUS_CPP_SPEC): Use %(cpp) not $(cpp_cpu).
        * config/alpha/linux.h (CPLUSPLUS_CPP_SPEC): Likewise.

Index: linux.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/linux.h,v
retrieving revision 1.11.4.2
diff -c -p -d -r1.11.4.2 linux.h
*** linux.h	2001/06/08 00:00:35	1.11.4.2
--- linux.h	2001/06/11 19:48:06
*************** Boston, MA 02111-1307, USA.  */
*** 75,86 ****
  #define CC1_SPEC "%{profile:-p}"
  #endif
  
! /* The GNU C++ standard library requires that these macros be
!    defined.  */
  #undef CPLUSPLUS_CPP_SPEC
! #define CPLUSPLUS_CPP_SPEC                      \
!   "-D_GNU_SOURCE                                \
!    %(cpp_cpu)"
  
  #ifndef USE_GNULIBC_1
  #undef DEFAULT_VTABLE_THUNKS
--- 75,83 ----
  #define CC1_SPEC "%{profile:-p}"
  #endif
  
! /* The GNU C++ standard library requires that these macros be defined.  */
  #undef CPLUSPLUS_CPP_SPEC
! #define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE %(cpp)"
  
  #ifndef USE_GNULIBC_1
  #undef DEFAULT_VTABLE_THUNKS
Index: alpha/linux.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/alpha/linux.h,v
retrieving revision 1.21.4.2
diff -c -p -d -r1.21.4.2 linux.h
*** alpha/linux.h	2001/06/09 00:37:29	1.21.4.2
--- alpha/linux.h	2001/06/11 19:48:06
*************** SUB_CPP_PREDEFINES
*** 30,36 ****
  
  /* The GNU C++ standard library requires that these macros be defined.  */
  #undef CPLUSPLUS_CPP_SPEC
! #define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE %(cpp_cpu)"
  
  #undef LIB_SPEC
  #define LIB_SPEC \
--- 30,36 ----
  
  /* The GNU C++ standard library requires that these macros be defined.  */
  #undef CPLUSPLUS_CPP_SPEC
! #define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE %(cpp)"
  
  #undef LIB_SPEC
  #define LIB_SPEC \

Re: G++ defining _GNU_SOURCE

[Joern Rennecke]

> (can't think of an easy way for linux.h to simply "prepend" -D_GNU_SOURCE
> to a previously-defined possibly empty CPLUSPLUS_CPP_DEFINE, rather than
> undef'ing it and fully redefining it.)

You can introduce a SUBTARGET_CPLUSPLUS_CPP_DEFINE, which defailts to empty
in pa.h, and is redefined in linux.h as "-D_GNU_SOURCE" .
You'd have to list SUBTARGET_CPLUSPLUS_CPP_DEFINE in EXTRA_SPECS.

For an example how such a thing is done, look at SUBTARGET_CPP_SPEC
in mips/config directory.  For an example how it is *not* done, look
at SUBTARGET_CPP_PREDEFINES in config/mcore ;-)

Re: G++ defining _GNU_SOURCE

[Joern Rennecke]

> 1. define CPLUSCPLUS_CPP_SPEC as "-D_GNU_SOURCE " + CPP_SPEC. Am I right to 
> assume that K&R doesn't support:
> 
> #define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE " CPP_SPEC

Yes.

> ? Or is there a way to do this in K&R? Otherwise most of the stuff between 
> CPP_SPEC and CPLUSPLUS_CPP_SPEC has to be shared (like aix51.h does) and 
> this looks quite error prone to me.

You can put the stuff for CPP_SPEC into an extra_spec, which is then used
both by CPP_SPEC and CPLUSPLUS_CPP_SPEC.