This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/3465: Using option -I/usr/include breaks bits/std_c*.h
- To: gcc-bugs at gcc dot gnu dot org
- Subject: Re: libstdc++/3465: Using option -I/usr/include breaks bits/std_c*.h
- From: Pierre Sarrazin <sarrazip at sympatico dot ca>
- Date: Wed, 11 Jul 2001 00:09:07 -0400
From: neil at gcc dot gnu dot org
Date: 28 Jun 2001 19:51:00 -0000
(http://gcc.gnu.org/ml/gcc-bugs/2001-06/msg01510.html)
>
> Synopsis: Using option -I/usr/include breaks bits/std_c*.h
>
> State-Changed-From-To: open->closed
> State-Changed-By: neil
> State-Changed-When: Thu Jun 28 12:51:00 2001
> State-Changed-Why:
> Don't use -I/usr/include; it's wrong for this reason (KDE, right?).
>
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3465&database=gcc
It is not so easy to avoid giving -I/usr/include to gcc.
I am trying to compile gnomemm-1.2.0:
http://sourceforge.net/project/showfiles.php?group_id=1161
Its configure script tries to compile a gtk-- test program, but
that fails under g++ 3.0. The -I/usr/include switch comes from
scripts like gtkmm-config or gnome-config, or from the gnome--.m4
Autoconf macro of the gnomemm project. Actually, those scripts
use an expression like -I$prefix/include, which only becomes a
problem if $prefix is /usr.
I have tried to patch the gnomemm configure script so that it would
take out all occurences of -I/usr/include with a `sed' command,
but I failed and gave up. It would be much easier if gcc 3.0
behaved correctly, like 2.95.2 did.
Can someone point me to the place in the gcc 3.0 sources where
I could cancel the code that is responsible for this problem?
Thanks.
--
Pierre Sarrazin <sarrazip at sympatico dot ca>