the _GNU_SOURCE blues

the _GNU_SOURCE blues

[Stefan Seefeld]

hi there,

I have been following the discussions on this list over the last couple
of weeks, and I understand that libstdc++ currently needs _GNU_SOURCE
which is the reason that the spec file defines it for g++ by default.

What I'm surprised about is that in the release gcc itself doesn't
define it. I remember this having changed forth and back, but I thought
there was agreement that it is a bug if gcc and g++ see different things.

The problem for me (and probably others too) is that most autoconf tests
use gcc for the tests, so the environment that is detected differs from
the one seen by g++ in the built.

I do know that I could switch to C++ for the relevant autoconf tests,
but that seems to open a whole new can of worms - there seem to be a couple
of bugs in autoconf when used with C++...

Beside, 'cc' isn't defined with a new gcc 3.0 installation, so some tests
that use 'cc' will see my older compiler only.

Anyways, since I don't want to sound only negative on such a great day,
thousand thanks to all the developers for the efford put into this release !

Regards,
		Stefan

Re: the _GNU_SOURCE blues

[David Edelsohn]

>>>>> Stefan Seefeld writes:

Stefan> I have been following the discussions on this list over the last couple
Stefan> of weeks, and I understand that libstdc++ currently needs _GNU_SOURCE
Stefan> which is the reason that the spec file defines it for g++ by default.

	It only is defined for GNU libc systems.

Stefan> What I'm surprised about is that in the release gcc itself doesn't
Stefan> define it. I remember this having changed forth and back, but I thought
Stefan> there was agreement that it is a bug if gcc and g++ see different things.

Stefan> The problem for me (and probably others too) is that most autoconf tests
Stefan> use gcc for the tests, so the environment that is detected differs from
Stefan> the one seen by g++ in the built.

	Where was this agreement made?  G++ needs a lot of additional
macros.  This is why CPLUSPLUS_CPP_SPEC was added.

David

Re: the _GNU_SOURCE blues

[Phil Edwards]

On Mon, Jun 18, 2001 at 09:58:55PM -0500, Stefan Seefeld wrote:
> I have been following the discussions on this list over the last couple
> of weeks, and I understand that libstdc++ currently needs _GNU_SOURCE

Only GNU systems, not all systems.

> which is the reason that the spec file defines it for g++ by default.

Not anymore.  This was fixed for the 3.0 release.

All compilers (all languages) will define it all the time, but only on
those systems which need it (e.g., linux).


-- 
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: the _GNU_SOURCE blues

[Stefan Seefeld]

Phil Edwards wrote:
> 
> On Mon, Jun 18, 2001 at 09:58:55PM -0500, Stefan Seefeld wrote:
> > I have been following the discussions on this list over the last couple
> > of weeks, and I understand that libstdc++ currently needs _GNU_SOURCE
> 
> Only GNU systems, not all systems.
> 
> > 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.
Instead, it seems to be burried deeply inside the gcc source code, as the
following test proves.
Trying to compile a file 'strsignal.c' which does a test that otherwise would
be done by configure, I see this:

------------------

bash$ g++ -v -c ~/strsignal.c 
Reading specs from /usr/local/gcc-3.0/lib/gcc-lib/i686-pc-linux-gnu/3.0/specs
Configured with: ../gcc-3.0/configure --enable-shared --enable-threads --prefix=/usr/local/gcc-3.0
Thread model: posix
gcc version 3.0
 /usr/local/gcc-3.0/lib/gcc-lib/i686-pc-linux-gnu/3.0/cc1plus -v -D__GNUC__=3 -D__GNUC_MINOR__=0
-D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux
-Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_GNU_SOURCE -Acpu=i386 -Amachine=i386 -Di386
-D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ /home/stefan/strsignal.c -D__GNUG__=3
-D__GXX_DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -quiet -dumpbase strsignal.c -version -o
/tmp/cchVPVID.s
GNU CPP version 3.0 (cpplib) (i386 Linux/ELF)
GNU C++ version 3.0 (i686-pc-linux-gnu)
        compiled by GNU C version 3.0.
ignoring nonexistent directory "/usr/local/gcc-3.0/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/gcc-3.0/include/g++-v3
 /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu
 /usr/local/gcc-3.0/include/g++-v3/backward
 /usr/local/include
 /usr/local/gcc-3.0/lib/gcc-lib/i686-pc-linux-gnu/3.0/include
 /usr/include
End of search list.
 as --traditional-format -V -Qy -o strsignal.o /tmp/cchVPVID.s
GNU assembler version 2.9.5 (i386-redhat-linux) using BFD version 2.9.5.0.22
bash$ 

------------------

bash$ gcc -v -c ~/strsignal.c 
Reading specs from /usr/local/gcc-3.0/lib/gcc-lib/i686-pc-linux-gnu/3.0/specs
Configured with: ../gcc-3.0/configure --enable-shared --enable-threads --prefix=/usr/local/gcc-3.0
Thread model: posix
gcc version 3.0
 /usr/local/gcc-3.0/lib/gcc-lib/i686-pc-linux-gnu/3.0/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=0
-D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux
-Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386
-D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ /home/stefan/strsignal.c -quiet -dumpbase
strsignal.c -version -o /tmp/ccVPNnzq.s
GNU CPP version 3.0 (cpplib) (i386 Linux/ELF)
GNU C version 3.0 (i686-pc-linux-gnu)
        compiled by GNU C version 3.0.
ignoring nonexistent directory "/usr/local/gcc-3.0/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/gcc-3.0/lib/gcc-lib/i686-pc-linux-gnu/3.0/include
 /usr/include
End of search list.
/home/stefan/strsignal.c: In function `main':
/home/stefan/strsignal.c:32: `strsignal' undeclared (first use in this function)
/home/stefan/strsignal.c:32: (Each undeclared identifier is reported only once
/home/stefan/strsignal.c:32: for each function it appears in.)
bash$ 

----------------

which clearly shows that both, g++ and gcc, don't see the same environment.

Regards,
		Stefan

Re: the _GNU_SOURCE blues

[Phil Edwards]

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.

Re: the _GNU_SOURCE blues

[Alexandre Oliva]

On Jun 19, 2001, Stefan Seefeld <seefeld@sympatico.ca> wrote:

> Instead, it seems to be burried deeply inside the gcc source code, as the
> following test proves.

All this test proves is that C++ requires declarations of functions
and C doesn't.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me