This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/3047: g++ does not define _LANGUAGE_C_PLUS_PLUS needed for <signal.h> on IRIX
- To: drk at sgi dot com
- Subject: Re: c++/3047: g++ does not define _LANGUAGE_C_PLUS_PLUS needed for <signal.h> on IRIX
- From: Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>
- Date: 05 Jun 2001 14:32:10 +0200
- Cc: gcc-gnats at gcc dot gnu dot org, johnv at adacel dot com dot au, gcc-bugs at gcc dot gnu dot org
- References: <20010604150304.13960.qmail@sourceware.cygnus.com>
drk@sgi.com writes:
> % cat hello.cpp
> #include <signal.h>
>
> void sig_handler(int sig) {
> exit (0);
> }
>
> int main() {
> signal(SIGTERM,sig_handler);
> }
> % g++ -o with -D_LANGUAGE_C_PLUS_PLUS hello.cpp
> ld32: WARNING 84 : /usr/local/lib/gcc-lib/mips-sgi-irix6.5/2.95.1/libstdc++.a is not used for resolving any symbol.
> ld32: WARNING 84 : /usr/lib32/libm.so is not used for resolving any symbol.
> % g++ -o without hello.cpp
> hello.cpp: In function `int main()':
> hello.cpp:8: ANSI C++ prohibits conversion from `(int)' to `(...)'
Currently, g++ (in config/mips/mips.h (CPP_SPEC)) bases the decision
whether or not to define _LANGUAGE_C_PLUS_PLUS on the source files'
extension. Renaming the file to one of hello.cc, hello.cxx, or hello.C
works around this problem for the moment. If I can find out how to test
what language is currently being compiled (the -x <language> switch) and
how to test this in a spec, I'll submit a patch to fix the problem this
(obviously better) way.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
Email: ro@TechFak.Uni-Bielefeld.DE