* the _GNU_SOURCE blues
@ 2001-06-18 19:00 Stefan Seefeld
2001-06-19 7:52 ` David Edelsohn
2001-06-19 9:59 ` Phil Edwards
0 siblings, 2 replies; 6+ messages in thread
From: Stefan Seefeld @ 2001-06-18 19:00 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: the _GNU_SOURCE blues
2001-06-18 19:00 the _GNU_SOURCE blues Stefan Seefeld
@ 2001-06-19 7:52 ` David Edelsohn
2001-06-19 9:59 ` Phil Edwards
1 sibling, 0 replies; 6+ messages in thread
From: David Edelsohn @ 2001-06-19 7:52 UTC (permalink / raw)
To: Stefan Seefeld; +Cc: gcc
>>>>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: the _GNU_SOURCE blues
2001-06-18 19:00 the _GNU_SOURCE blues Stefan Seefeld
2001-06-19 7:52 ` David Edelsohn
@ 2001-06-19 9:59 ` Phil Edwards
2001-06-19 10:35 ` Stefan Seefeld
1 sibling, 1 reply; 6+ messages in thread
From: Phil Edwards @ 2001-06-19 9:59 UTC (permalink / raw)
To: Stefan Seefeld; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: the _GNU_SOURCE blues
2001-06-19 9:59 ` Phil Edwards
@ 2001-06-19 10:35 ` Stefan Seefeld
2001-06-19 10:53 ` Phil Edwards
2001-06-20 17:27 ` Alexandre Oliva
0 siblings, 2 replies; 6+ messages in thread
From: Stefan Seefeld @ 2001-06-19 10:35 UTC (permalink / raw)
To: Phil Edwards; +Cc: gcc
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: the _GNU_SOURCE blues
2001-06-19 10:35 ` Stefan Seefeld
@ 2001-06-19 10:53 ` Phil Edwards
2001-06-20 17:27 ` Alexandre Oliva
1 sibling, 0 replies; 6+ messages in thread
From: Phil Edwards @ 2001-06-19 10:53 UTC (permalink / raw)
To: Stefan Seefeld; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: the _GNU_SOURCE blues
2001-06-19 10:35 ` Stefan Seefeld
2001-06-19 10:53 ` Phil Edwards
@ 2001-06-20 17:27 ` Alexandre Oliva
1 sibling, 0 replies; 6+ messages in thread
From: Alexandre Oliva @ 2001-06-20 17:27 UTC (permalink / raw)
To: Stefan Seefeld; +Cc: Phil Edwards, gcc
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-06-20 17:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-18 19:00 the _GNU_SOURCE blues Stefan Seefeld
2001-06-19 7:52 ` David Edelsohn
2001-06-19 9:59 ` Phil Edwards
2001-06-19 10:35 ` Stefan Seefeld
2001-06-19 10:53 ` Phil Edwards
2001-06-20 17:27 ` Alexandre Oliva
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).