This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: the _GNU_SOURCE blues


On Tue, Jun 19, 2001 at 01:35:23PM -0500, Stefan Seefeld wrote:
> > > which is the reason that the spec file defines it for g++ by default.
> > 
> > Not anymore.  This was fixed for the 3.0 release.
> 
> The spec file does indeed not contain the _GNU_SOURCE symbol any more.

Ah, my apologies.  I misunderstood where you were going with your argument.

Yes, on certain systems the C++ compiler will always define this preprocessor
symbol.  (I say "the C++ compiler" because you can use 'gcc' or 'g++'
and the same compiler will fire; see the GCC Manual for more on this.)

As you noted, there was a lot of discussion about this.  Right now, a C++
environment on some systems simply uses more symbols than a C environment
does.  There are other symbols besides _GNU_SOURCE which also get predefined
automatically; _GNU_SOURCE just happens to be more visible.

If a package intends to use the C++ compiler to build its code, then
it should tell autoconf to use the C++ compiler when running its tests.
Doing otherwise would be a bug in that package, just as if I intended to
use the FORTRAN compiler to build my code but used an Ada compiler to test
the system; they are /different/ lanaguages.

Now, if a C compiler and a C++ compiler should be giving the same results
on an autoconf test, but they do not, then that's a different kind of bug.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]