This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: New cpp0 warning in 3.1 breaks configure (autoconf)
- From: H}kan Hjort <d95hjort at dtek dot chalmers dot se>
- To: gcc-bugs at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Cc: Nathan Sidwell <nathan at codesourcery dot com>,Phil Edwards <phil at jaj dot com>, DJ Delorie <dj at redhat dot com>
- Date: Sat, 8 Jun 2002 00:44:07 +0200
- Subject: Re: New cpp0 warning in 3.1 breaks configure (autoconf)
- References: <20020606204404.GA17526@bort.dtek.chalmers.se>
A.k.a "changing search order for system directory"
Let me try to exemplify. The following configure script will fail
if --with-breakme=/usr/include (or any other default system include
path, like /usr/local/include on most systems) is given.
This is new with GCC 3.1.
To complicate things further BSD does not have /usr/local/include as a
default include directory so testing for that and excluding it will not
work.
--begin configure.in--
AC_INIT(configure.in)
AC_PROG_CC
dnl First one to force it to figure out that gcc -E is a good preprocessor
AC_CHECK_HEADER(stdlib.h)
saved_CPPFLAGS=$CPPFLAGS
AC_ARG_WITH(breakme,
[ --with-breakme=path specify a location of the headers files to use ],
CPPFLAGS="$CPPFLAGS -I$withval")
AC_CHECK_HEADER(string.h,,[AC_MSG_ERROR([Didn't find string.h])])
CPPFLAGS=$saved_CPPFLAGS
AC_OUTPUT(Makefile)
--end configure.in--
Running this (after autoconf) as shown below ends with an error.
>$ ./configure --with-breakme=/usr/local/include
...
checking for string.h... no
configure: error: Some thing is seriously messed up
>$ tail -8 config.log
configure:875: checking for string.h
configure:885: gcc3 -E -I/usr/local/include conftest.c >/dev/null 2>conftest.out
cpp0: warning: changing search order for system directory "/usr/local/include"
cpp0: warning: as it has already been specified as a non-system directory
configure: failed program was:
#line 880 "configure"
#include "confdefs.h"
#include <string.h>
Here is another message http://gcc.gnu.org/ml/gcc/2001-07/msg00470.html
from last year that takes up the problem with this 'default on' no way
to turn it off warning. (Not exatly the same problem but..)
And reports in that thread of extra failurs in the testsuite from this
change.
Further evidens of problems with these warnings can be found here
http://gcc.gnu.org/ml/gcc-bugs/2002-04/msg00149.html
Where can the forbidden directories be found?
(Guessing based on gcc -v -E ..., /usr/local/include /usr/include)
Is there anyway to get rid of this warning? Why is it on by default?
How are one supposed to workaround this in configure scripts?
--
Håkan Hjort
d95hjort@dtek.chalmers.se