Re: gcc 3.2's cpp breaks configure scripts

Re: gcc 3.2's cpp breaks configure scripts

[H}kan Hjort]

John David Anglin wrote:
> The gcc warning is correct in the cases that I have examined.  I don't
> believe that configure should be adding include directories to CPPFLAGS
> that are already being searched as system directories by gcc.  This
> changes the include search order as noted in the warning and may
> cause unexpected results.
>
Ah but which are theses directories?  There is no way to know as far
as I can see.  (If you don't fancy doing some rather serious parsing
of either the specfile, the output from -dumpspecs or from gcc -v -E).

Since some thimes for example /usr/local/include will be a system
directory and some times not.

[snip]
> There may be some debate as to what directories gcc should treat
> as "system" directories.  However, configure shouldn't change
> the default search order of gcc without good reason, irrespective
> of whether the directories are truly system directories or not.
> this affects gcc's mechanism to fix headers.

Ehh.. not everyone installs every pice of software out there in /usr
so then you need to tell configure where to find the stuff, and it in
turn needs to add the -I and -L / -R flags.

Now if user says that 'oh I have libjpeg installed in /usr/local', 
should I then add -I/usr/local/include to CPPFLAGS or not?

If I do so on a standard Linux system it will fail becuse of:
cpp0: warning: changing search order for system directory "/usr/local/include"
cpp0: warning:   as it has already been specified as a non-system directory

on the other hand if I don't then on a FreeBSD system it will fail with:
conftest.c:4:17: jpeglib.h: No such file or directory

[snip]
> Possibly, if gcc provided a simpler way to print the search order,
> the autoconf macro authors could be persuaded not to append these
> directories to CPPFLAGS.  The reasons to do this are documented.
> Turning the warning off is not the correct solution, although there
> may be some circumstances in which it is emitted when it shouldn't
> be.

Or if there where autoconf macros that handled all of this instead of
each package having the code to let users specify if/where a dependecy
can be found.  Then trying to work out if the path must or must _not_
be added.

The fact that there still are many configure scripts out there that now
fail just because of this, still stands.  The only way to turn of this
warning is with -w  'Inhibit warning messages'.
I don't know if adding that to CPPFLAGS will cause any other averse 
affects.

-- 
HÃ¥kan Hjort

Re: gcc 3.2's cpp breaks configure scripts

[John David Anglin]

> John David Anglin wrote:
> > The gcc warning is correct in the cases that I have examined.  I don't
> > believe that configure should be adding include directories to CPPFLAGS
> > that are already being searched as system directories by gcc.  This
> > changes the include search order as noted in the warning and may
> > cause unexpected results.
> >
> Ah but which are theses directories?  There is no way to know as far
> as I can see.  (If you don't fancy doing some rather serious parsing
> of either the specfile, the output from -dumpspecs or from gcc -v -E).

Enclosed is a patch to the gettext macros lib-link.m4 and lib-prefix.m4
to prevent them from appending GCC system directories to CPPFLAGS.  It
uses "gcc -v -E" and checks for the warning.  I have tested the patch
by building textutils-2.1 using the new macros.  Possibly, the macros
can be improved but the patch seems to be doing what I want.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-07-31  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* lib-link.m4: Don't add GCC system include directories to CPPFLAGS.
	* lib-prefix.m4: Likewise.

--- lib-link.m4.orig	Sat Jul 20 03:15:04 2002
+++ lib-link.m4	Thu Aug  1 21:57:16 2002
@@ -345,9 +345,10 @@
               dnl But don't add it
               dnl   1. if it's the standard /usr/include,
               dnl   2. if it's /usr/local/include and we are using GCC on Linux,
-              dnl   3. if it's already present in $CPPFLAGS or the already
+              dnl   3. if it doesn't exist as a directory.
+              dnl   4. if it's a GCC system include directory,
+              dnl   5. if it's already present in $CPPFLAGS or the already
               dnl      constructed $INCNAME,
-              dnl   4. if it doesn't exist as a directory.
               if test "X$additional_includedir" != "X/usr/include"; then
                 haveit=
                 if test "X$additional_includedir" = "X/usr/local/include"; then
@@ -358,6 +359,17 @@
                   fi
                 fi
                 if test -z "$haveit"; then
+                  if test -d "$additional_includedir"; then
+                    if test -n "$GCC"; then
+                      if test -n "`echo 'main (){}' | $CC -v -E -I$additional_includedir - 2>&1 | grep 'changing search order for system directory'`"; then
+                        haveit=yes
+                      fi
+                    fi
+                  else
+                    haveit=yes
+                  fi
+                fi
+                if test -z "$haveit"; then
                   for x in $CPPFLAGS $INC[]NAME; do
                     AC_LIB_WITH_FINAL_PREFIX([eval x=\"$x\"])
                     if test "X$x" = "X-I$additional_includedir"; then
@@ -366,10 +378,8 @@
                     fi
                   done
                   if test -z "$haveit"; then
-                    if test -d "$additional_includedir"; then
-                      dnl Really add $additional_includedir to $INCNAME.
-                      INC[]NAME="${INC[]NAME}${INC[]NAME:+ }-I$additional_includedir"
-                    fi
+                    dnl Really add $additional_includedir to $INCNAME.
+                    INC[]NAME="${INC[]NAME}${INC[]NAME:+ }-I$additional_includedir"
                   fi
                 fi
               fi
--- lib-prefix.m4.orig	Sat Feb 16 06:24:09 2002
+++ lib-prefix.m4	Thu Aug  1 22:00:57 2002
@@ -51,6 +51,7 @@
     dnl   2. if it's already present in $CPPFLAGS,
     dnl   3. if it's /usr/local/include and we are using GCC on Linux,
     dnl   4. if it doesn't exist as a directory.
+    dnl   5. if it's a GCC system include directory,
     if test "X$additional_includedir" != "X/usr/include"; then
       haveit=
       for x in $CPPFLAGS; do
@@ -68,11 +69,20 @@
             esac
           fi
         fi
-        if test -z "$haveit"; then
-          if test -d "$additional_includedir"; then
-            dnl Really add $additional_includedir to $CPPFLAGS.
-            CPPFLAGS="${CPPFLAGS}${CPPFLAGS:+ }-I$additional_includedir"
+      fi
+      if test -z "$haveit"; then
+        if test -d "$additional_includedir"; then
+          if test -n "$GCC"; then
+            if test -n "`echo 'main (){}' | $CC -v -E -I$additional_includedir - 2>&1 | grep 'changing search order for system directory'`"; then
+              haveit=yes
+            fi
           fi
+        else
+          haveit=yes
+        fi
+        if test -z "$haveit"; then
+          dnl Really add $additional_includedir to $CPPFLAGS.
+          CPPFLAGS="${CPPFLAGS}${CPPFLAGS:+ }-I$additional_includedir"
         fi
       fi
     fi

Re: gcc 3.2's cpp breaks configure scripts

[Bruno Haible]

John David Anglin writes:
> Enclosed is a patch to the gettext macros lib-link.m4 and lib-prefix.m4
> to prevent them from appending GCC system directories to CPPFLAGS.  It
> uses "gcc -v -E" and checks for the warning.

The patch does the wrong thing in half of the cases.

If the added directory is one of the directories on which fixincludes
is run, then
  1. gcc's warning is justified,
  2. Users shouldn't install additional packages (such as libintl,
     libiconv etc.) in this directory. It won't work because the
     include file seen by gcc might be the fixincluded one, which
     represents a different version of the package than the one
     which is being installed as a library.
     It'd be good if the GCC documentation mentioned this pitfall.

If the added directory is not a fixincluded one, then there is no
reason for GCC warning - except for Jakub's arguments.

Jakub Jelinek writes:

> > you're saying that adding -I/usr/include (or similar) can cause libstdc++ 
> > headers to break due to the way they use #include_next?
> Yes.

Then indeed it would be wrong to add -Idir to the command line. But
then also, you should document in the GCC documentation that users
should not install packages in these directories. Because any freshly
installed .h file in such a directory may be hidden by the ones in
gcc's private gcc-lib/platform/version/include directory, which are
older but have not been updated.

In this case, it'd be best for autoconf macro authors if gcc provided
an easy to use, documented way to test whether a directory is
forbidden for -I or not. I'd then use this test in two situations:
  1) When searching for a library and its include files, this
     directory shall be skipped, even if it equals $prefix/include,
  2) When installing a library, configure will refuse to install in
     such a forbidden directory.

> Also, -I/usr/include changes the status of /usr/include headers from
> system headers to user headers, thus you may get warnings (or errors
> with -Werror) where you otherwise would not get any.

This is an indication that cpp's heuristic to distinguish "user" and
"system" heads is wrong.

Bruno

Re: gcc 3.2's cpp breaks configure scripts

[John David Anglin]

> John David Anglin writes:
> > Enclosed is a patch to the gettext macros lib-link.m4 and lib-prefix.m4
> > to prevent them from appending GCC system directories to CPPFLAGS.  It
> > uses "gcc -v -E" and checks for the warning.
> 
> The patch does the wrong thing in half of the cases.

Which cases are these?  Irrespective of whether or not the directory
is truly a "system" directory, the patch detects directories that
gcc will search.  A "-I" is unnecessary for these directories unless
you actually want to change the search order.   This is dangerous
unless you have intimate knowledge of how the system is configured.

Gcc has a predefined search order for its "system" directories
and I have yet to see a convincing reason why its necessary to change
this order for building packages which use the gettext macros.  The
only situation where I can see a problem is when a header is
installed in two of the directories searched automatically by gcc
and the user attempts to select the one that is searched second.
With my patch, you will get the header in the first directory
rather than the one in the second directory and this could cause
a problem due to inconsistent versions.  I would prefer configure
checked for this than give up the predefined search order.

As noted in previous mail, gcc searches both /usr/local/include and
/opt/gnu/include when it is configured with /opt/gnu, so if you
add -I/opt/gnu the search order of the two directories is changed.
This may cause different headers to be used and cause unexpected
results for other headers depending on how the system is configured.

> If the added directory is one of the directories on which fixincludes
> is run, then
>   1. gcc's warning is justified,
>   2. Users shouldn't install additional packages (such as libintl,
>      libiconv etc.) in this directory. It won't work because the
>      include file seen by gcc might be the fixincluded one, which
>      represents a different version of the package than the one
>      which is being installed as a library.
>      It'd be good if the GCC documentation mentioned this pitfall.

Yes, that's a valid point.  In the case at hand, none of the above
were installed in a fixincludes directory.  The main point of debate
is whether or not the search order of non-fixinclude include directories
should by changeable without a warning.  Personally, I think it's a
mugs game to try rearrange the header search order to select a
specific set of headers.

> > Also, -I/usr/include changes the status of /usr/include headers from
> > system headers to user headers, thus you may get warnings (or errors
> > with -Werror) where you otherwise would not get any.
> 
> This is an indication that cpp's heuristic to distinguish "user" and
> "system" heads is wrong.

Agreed.  However, I think we have to live with the fixinclude scheme
and the fact that gcc has a set of include directories that it searches
in a predefined order.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc 3.2's cpp breaks configure scripts

[Paul Eggert]

> From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
> Date: Fri, 2 Aug 2002 15:29:29 -0400 (EDT)
> 
> As noted in previous mail, gcc searches both /usr/local/include and
> /opt/gnu/include when it is configured with /opt/gnu, so if you
> add -I/opt/gnu the search order of the two directories is changed.
> This may cause different headers to be used and cause unexpected
> results for other headers depending on how the system is configured.

But GCC warns in many cases where there is no problem.  It is crying
wolf far too often in practice.  People are learning to ignore those
warnings.

I am considering putting a sed filter around GCC to remove these
warnings entirely.  But, more likely, I will install GCC in a
nonstandard place, so that it doesn't include my local equivalent of
/opt/gnu/include by default.  I think that's what Bruno's sysadmin
does.  It is an ugly solution (e.g., it means I'll see
"-I/opt/gnu/include" a lot), but it beats dealing with this hassle all
the time.

If GCC warned only when there was a real problem, a lot of these issues
would go away.

> The main point of debate is whether or not the search order of
> non-fixinclude include directories should by changeable without a
> warning.  Personally, I think it's a mugs game to try rearrange the
> header search order to select a specific set of headers.

In all the cases where I've seen this warning, the header search order
did not matter, and the files behaved identically in "user" and
"system" mode, so GCC's warning was inappropriate.

> > > Also, -I/usr/include changes the status of /usr/include headers from
> > > system headers to user headers, thus you may get warnings (or errors
> > > with -Werror) where you otherwise would not get any.
> > 
> > This is an indication that cpp's heuristic to distinguish "user" and
> > "system" heads is wrong.
> 
> Agreed.  However, I think we have to live with the fixinclude scheme

No, we could fix system includes files on every run of GCC, for
example.  In the old days that would have been impractical for
performance reasons, but nowadays the hassle of dealing with this
problem outweighs any minor slowdowns that would accrue from fixing
system include files dynamically.

There are other possible solutions too, basically building on the
__STDC__ idea that GCC already uses.

This problem is becoming a major inconvenience in using GCC, and it
would be nice if someone would fix it.

Re: gcc 3.2's cpp breaks configure scripts

[Nix]

On Fri, 2 Aug 2002, Paul Eggert said:
> If GCC warned only when there was a real problem, a lot of these issues
> would go away.

Alternatively, GCC could simply ignore the -I switches that would
trigger those warnings in situations where those warnings are now
emitted. Is there ever any reason you'd *want* GCC to do that
reordering? I can't think of any occasion when I'd want to avoid
fixincluded headers... they have after all been fixincluded for a
reason (and if the fixincluded headers are broken the solution is
to delete the broken ones and fix fixincludes, not to supply
an extra -I/usr/include switch to everything!)

-- 
`There's something satisfying about killing JWZ over and over again.'
                                        -- 1i, personal communication

Re: gcc 3.2's cpp breaks configure scripts

[John David Anglin]

> > As noted in previous mail, gcc searches both /usr/local/include and
> > /opt/gnu/include when it is configured with /opt/gnu, so if you
> > add -I/opt/gnu the search order of the two directories is changed.
> > This may cause different headers to be used and cause unexpected
> > results for other headers depending on how the system is configured.
> 
> But GCC warns in many cases where there is no problem.  It is crying
> wolf far too often in practice.  People are learning to ignore those
> warnings.

Here is the history of the situation as I understand it:

1)  gcc 2.95 and earlier simply added directories to the search list
    without any checks for redundency or changes from system to
    non-system.  As a result, a directory can appear multiple
    times in the search list.

2)  gcc 3.0.x issues warning "ignoring duplicate directory"
    when a duplicate directory is specified and the "-v" option
    is used.

3)  gcc 3.1.x issue warning "cpp0: warning: changing search order
    for system directory" when a system directory is added with
    "-I".  There is no warning about changing the search
    order with "-isystem".  We still have the "ignoring duplicate
    directory" warning with "-v".

4)  gcc 3.3 is the same as gcc 3.1.x except "cpp0" is now "cc1".

All versions search the same set of directories:

  /usr/local/include
  /opt/gnu/include
  /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include
  /opt/gnu/hppa2.0w-hp-hpux11.00/include
  /usr/include

where "/opt/gnu" was the prefix used to build gcc for the target
hppa2.0w-hp-hpux11.00.

/usr/include is the only directory for which includes are fixed.

libstdc++ headers are installed in /opt/gnu/include unless the
gcc prefix is /usr/local, in which case they are installed in
/usr/local/include.  I stopped installing gcc and packages in
/usr/local since I need to install multiple configurations
(32-bit and 64-bit, etc).  It appears that installing gcc with
--prefix=/usr/local will effectively prevent other installations
from working properly as the g++-v3 headers will always be
found in /usr/local unless the user reorders the system headers.
The same is true for any package which installs headers to
/usr/local.  It might be better if the v3 headers were in
/opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include.

I believe that the automatic search of /usr/local/include is wrong
when gcc was configured with a prefix that is not /usr/local.  This
makes it very difficult for a user to install another version of
gcc in a different location and have it load the correct headers.

Searching for "include_next" in ${prefix}/include, I find two uses
under hppa-linux (a.out.h and limits.h) and none under hppa2.0w-hp-hpux11.
The two headers under hppa-linux are from glibc.  Thus, I agree
that there are very few situations where the headers loaded might
change as a result of reordering gcc's automatic search direcories.

> This problem is becoming a major inconvenience in using GCC, and it
> would be nice if someone would fix it.

1) The header search mechanism is implementation defined and thus
   autoconf and package developers will have to adopt to whatever
   schemes are used in gcc releases.  Possibly, Bruno would accept
   a modified version of my patch where we add gcc system headers
   to CPPFLAGS with "-isystem" instead of dropping them.  This will
   reorder the headers without the warning.  Another alterative
   is to use -nostdinc and -isystem to completely rebuild gcc's
   notion of system headers but this seems more complicated.

2) I would like to see the matter of the /usr/local/include reviewed.
   It definitely shouldn't be the first system include directory
   searched and possibly it shouldn't be searched automatically
   at all when gcc is configured with a prefix other than /usr/local.
   Reducing the number of system directories, simplifies the issues
   of header ordering.  As a result, the autoconf macros are less
   likely to have to add more than one "-isystem" directory and
   determine the ordering needed.  The current gettext macros
   don't attempt to reorder /usr/include.

3) The warning is ambiguous.  Is it about the change in search order
   or the change from a system include to a non-system include directory?
   Since there is no warning when "-isystem" is used, I suspect that
   the warning is about the change to a non-system directory.  In
   that case, we can do without warnings for /usr/local/include
   and /opt/gnu.

4) Let's move the v3 headers to gcc's private include directory so that
   correct versions are automatically used.

Comments?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc 3.2's cpp breaks configure scripts

[John David Anglin]

> On Fri, 2 Aug 2002, Paul Eggert said:
> > If GCC warned only when there was a real problem, a lot of these issues
> > would go away.
> 
> Alternatively, GCC could simply ignore the -I switches that would
> trigger those warnings in situations where those warnings are now
> emitted. Is there ever any reason you'd *want* GCC to do that

I think you have to assume the user knows best and wants the change
in ordering and error treatment.  If you want to test warnings from
system headers, you can use -nostdinc and configure system and user
headers as you wish.

> reordering? I can't think of any occasion when I'd want to avoid
> fixincluded headers... they have after all been fixincluded for a
> reason (and if the fixincluded headers are broken the solution is
> to delete the broken ones and fix fixincludes, not to supply
> an extra -I/usr/include switch to everything!)

Agreed but hey this is "unix".  Anybody know which autoconf macro
was responsible for the "-I/usr/include" in the original problem
report?  The current gettext macros which have caused problems
for me don't add /usr/include.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc 3.2's cpp breaks configure scripts

[Zack Weinberg]

I would appreciate it if people would not send gcc-related mail to
zackw@stanford.edu; that address is likely to stop working in the near
future, and in any case it forwards to an inconvenient location.

I'll make a substantive comment on John's other post.

zw

Re: gcc 3.2's cpp breaks configure scripts

[Gabriel Dos Reis]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:

[...]

| libstdc++ headers are installed in /opt/gnu/include unless the
| gcc prefix is /usr/local, in which case they are installed in
| /usr/local/include.  I stopped installing gcc and packages in
| /usr/local since I need to install multiple configurations
| (32-bit and 64-bit, etc).  It appears that installing gcc with
| --prefix=/usr/local will effectively prevent other installations
| from working properly as the g++-v3 headers will always be
| found in /usr/local unless the user reorders the system headers.
| The same is true for any package which installs headers to
| /usr/local.  It might be better if the v3 headers were in
| /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include.

Please note that with current source, V3 is installed in
${prefix}/include/c++/${version}/; and within that directory,
target-specific headers are installed in appropriate subdirectory.

-- Gaby

Re: gcc 3.2's cpp breaks configure scripts

[Zack Weinberg]

On Sat, Aug 03, 2002 at 05:42:11PM -0400, John David Anglin wrote:
> Here is the history of the situation as I understand it:
> 
> 1)  gcc 2.95 and earlier simply added directories to the search list
>     without any checks for redundency or changes from system to
>     non-system.  As a result, a directory can appear multiple
>     times in the search list.

Correct.

> 2)  gcc 3.0.x issues warning "ignoring duplicate directory"
>     when a duplicate directory is specified and the "-v" option
>     is used.

Yes.  (cpplib has done that for ages; you will, frex, get the warning
with some 2.96 and 2.97 era compilers.)  No one has ever objected to
this as far as I know.

> 3)  gcc 3.1.x issue warning "cpp0: warning: changing search order
>     for system directory" when a system directory is added with
>     "-I".  There is no warning about changing the search
>     order with "-isystem".  We still have the "ignoring duplicate
>     directory" warning with "-v".

Yes.  The warning was added in July 2001 by Nathan Sidwell.  The
original message proposing it is
http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00466.html - yes, May;
the discussion broke off and was resumed in July, starting at
http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00046.html

There is not much discussion of the rationale for the patch in this
context, just a mention of problems with libstdc++.  Nathan, would you
mind expanding a bit?

> 4)  gcc 3.3 is the same as gcc 3.1.x except "cpp0" is now "cc1".

Yah.

> All versions search the same set of directories:
> 
>   /usr/local/include
>   /opt/gnu/include
>   /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include
>   /opt/gnu/hppa2.0w-hp-hpux11.00/include
>   /usr/include
> 
> where "/opt/gnu" was the prefix used to build gcc for the target
> hppa2.0w-hp-hpux11.00.

As far as I can tell, 2.95 and 3.0 would not have searched
/opt/gnu/include (i.e. $(prefix)/include) at all.  Per Bothner 
changed this in September 2001, with this patch:
http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00519.html
It was generally agreed that not searching $(prefix)/include was a
bug.

> /usr/include is the only directory for which includes are fixed.

More accurately, $(SYSTEM_HEADER_DIR) is the only directory for which
includes are fixed.  There is $(OTHER_FIXINCLUDES_DIRS), but nothing
uses it.  SYSTEM_HEADER_DIR is normally /usr/include, but in a cross
compiler it's $(exec_prefix)/$(target_alias)/sys-include, and several
target fragments override it (incorrectly; they should be changing
NATIVE_SYSTEM_HEADER_DIR...)

> libstdc++ headers are installed in /opt/gnu/include unless the
> gcc prefix is /usr/local, in which case they are installed in
> /usr/local/include.  I stopped installing gcc and packages in
> /usr/local since I need to install multiple configurations
> (32-bit and 64-bit, etc).  It appears that installing gcc with
> --prefix=/usr/local will effectively prevent other installations
> from working properly as the g++-v3 headers will always be
> found in /usr/local unless the user reorders the system headers.
> The same is true for any package which installs headers to
> /usr/local.  It might be better if the v3 headers were in
> /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include.

I believe there were other bug reports requesting this move, too.
You'd have to take that up with the libstdc++ people though.

...
> 2) I would like to see the matter of the /usr/local/include reviewed.
>    It definitely shouldn't be the first system include directory
>    searched and possibly it shouldn't be searched automatically
>    at all when gcc is configured with a prefix other than /usr/local.
>    Reducing the number of system directories, simplifies the issues
>    of header ordering.  As a result, the autoconf macros are less
>    likely to have to add more than one "-isystem" directory and
>    determine the ordering needed.  The current gettext macros
>    don't attempt to reorder /usr/include.

There are two very good reasons why /usr/local/include is searched
independent of whether it's $(prefix)/include: First, if you are
building with prefix=/usr, (or prefix="", if you're those crazy Hurd
people) you still want /usr/local/include searched.  Second, if you
are a user installing gcc in their home directory (on a multi-user
system, where you don't have write privs anywhere else), again you
probably still want /usr/local/include searched.

Could you expand a bit on your assertion that this makes it difficult
for a user to install gcc in an unusual location and have it find the
correct headers, please?  I do not see how the problem arises.

> 3) The warning is ambiguous.  Is it about the change in search order
>    or the change from a system include to a non-system include directory?
>    Since there is no warning when "-isystem" is used, I suspect that
>    the warning is about the change to a non-system directory.

Correct; see above.

>    In that case, we can do without warnings for /usr/local/include
>    and /opt/gnu.

I do not see how this follows.  The problems caused by
-I <dir on system path> are not merely because of failure to pick up
fixincluded headers.  For instance, Dan Jacobowitz points out that
-I/usr/include can cause havoc when used with a cross compiler; it
seems to me that -I/usr/local/include could cause just as much havoc.
(He wanted these to warn in a cross configuration, which I must
confess I don't see any way to do - how do we know that
-I/gltz/quux/include happens to contain headers for the wrong target?

My inclination, for the record, is to do nothing until all parties
come to an agreement on what GCC's behavior _should_ be.  At present,
I suspect that any patch will be immediately followed by another horde
of objectors demanding it be put back the way it was.

zw

Re: gcc 3.2's cpp breaks configure scripts

[Gareth Pearce]

> On Fri, 2 Aug 2002, Paul Eggert said:
> > If GCC warned only when there was a real problem, a lot of these issues
> > would go away.
>
> Alternatively, GCC could simply ignore the -I switches that would
> trigger those warnings in situations where those warnings are now
> emitted. Is there ever any reason you'd *want* GCC to do that
> reordering? I can't think of any occasion when I'd want to avoid
> fixincluded headers... they have after all been fixincluded for a
> reason (and if the fixincluded headers are broken the solution is
> to delete the broken ones and fix fixincludes, not to supply
> an extra -I/usr/include switch to everything!)

I agree that this is what I would like to see - however 2 points
1. Someone will complain about lack of flexibility, so there has to be a way
to disable this overide.
2.  Its possibly somewhat 'antistandard' to overide the passed parameters,
so this feature should Possibly default to off.

Gareth

Re: gcc 3.2's cpp breaks configure scripts

[John David Anglin]

> Yes.  (cpplib has done that for ages; you will, frex, get the warning
> with some 2.96 and 2.97 era compilers.)  No one has ever objected to
> this as far as I know.

I have no objection to this.  I pointed it out because it is one possible
method to determine whether a given directory is a gcc system include
directory before 3.3.

> There is not much discussion of the rationale for the patch in this
> context, just a mention of problems with libstdc++.  Nathan, would you
> mind expanding a bit?

From what Jakub has mention, it revolves around the treatment of
include_next.  Part of the reason I thought the v3 header might
might be better in gcc's private header directory was because
some systems appear to use wrap v3 headers and I couldn't conceive
of any reason why an application developer would want to reorder
gcc's search path from this point onward although I must admit
the thread started with an attempt to reorder /usr/include.

> > All versions search the same set of directories:
> > 
> >   /usr/local/include
> >   /opt/gnu/include
> >   /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include
> >   /opt/gnu/hppa2.0w-hp-hpux11.00/include
> >   /usr/include
> > 
> > where "/opt/gnu" was the prefix used to build gcc for the target
> > hppa2.0w-hp-hpux11.00.
> 
> As far as I can tell, 2.95 and 3.0 would not have searched
> /opt/gnu/include (i.e. $(prefix)/include) at all.  Per Bothner 
> changed this in September 2001, with this patch:
> http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00519.html
> It was generally agreed that not searching $(prefix)/include was a
> bug.

I find this very convenient because on the PA I do builds for both
32-bit and 64-bit code, and there is at the moment no way to integrate
the two.  Thus, I use separate prefix for the two.  I can't use
/usr/local/lib for libraries because the 32 and 64-bit libraries
have the same name.

> > libstdc++ headers are installed in /opt/gnu/include unless the

Gabriel pointed out that v3 now uses a version scheme for headers.
However, it appears the 3.1/3.2 branch and before uses g++-v3.

> > gcc prefix is /usr/local, in which case they are installed in
> > /usr/local/include.  I stopped installing gcc and packages in
> > /usr/local since I need to install multiple configurations
> > (32-bit and 64-bit, etc).  It appears that installing gcc with
> > --prefix=/usr/local will effectively prevent other installations
> > from working properly as the g++-v3 headers will always be
> > found in /usr/local unless the user reorders the system headers.
> > The same is true for any package which installs headers to
> > /usr/local.  It might be better if the v3 headers were in
> > /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include.
> 
> I believe there were other bug reports requesting this move, too.
> You'd have to take that up with the libstdc++ people though.
> 
> ...
> > 2) I would like to see the matter of the /usr/local/include reviewed.
> >    It definitely shouldn't be the first system include directory
> >    searched and possibly it shouldn't be searched automatically
> >    at all when gcc is configured with a prefix other than /usr/local.
> >    Reducing the number of system directories, simplifies the issues
> >    of header ordering.  As a result, the autoconf macros are less
> >    likely to have to add more than one "-isystem" directory and
> >    determine the ordering needed.  The current gettext macros
> >    don't attempt to reorder /usr/include.
> 
> There are two very good reasons why /usr/local/include is searched
> independent of whether it's $(prefix)/include: First, if you are
> building with prefix=/usr, (or prefix="", if you're those crazy Hurd
> people) you still want /usr/local/include searched.  Second, if you

Special cases.

> are a user installing gcc in their home directory (on a multi-user
> system, where you don't have write privs anywhere else), again you
> probably still want /usr/local/include searched.

I'm not convinced of this one.  This is not much of an example but
HP compilers only search /usr/include by default.  When you add
additional directories to the search it gets complicated to bypass
them.  When a user installs gcc in their home directory, I think
they are better off explicitly adding /usr/local/include when
needed.

> Could you expand a bit on your assertion that this makes it difficult
> for a user to install gcc in an unusual location and have it find the
> correct headers, please?  I do not see how the problem arises.

The issue arises if a user installs a different version of a package
with headers from the one installed in /usr/local.  I think
the default gcc search will pick up headers from  /usr/local/include
in preference to ${gcc_install_prefix}/include.  However, there is
something strange here with respect to the v3 headers:

echo 'main(){}'|/home/dave/opt/gnu/gcc/gcc-3.1/bin/g++ -v -E -|less
...
gcc version 3.1
...
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /home/dave/opt/gnu/gcc/gcc-3.1/include
 /home/dave/opt/gnu/gcc/gcc-3.1/lib/gcc-lib/hppa-linux/3.1/include
 /usr/include
End of search list.
...

dave@gsyprf11:~/opt/gnu/include$ ll -l /usr/local/include/g++-v3/algorithm
-rw-r--r--    1 root     staff        2973 Apr 24 20:47 /usr/local/include/g++-v3/algorithm

However, with the simple program

dave@gsyprf11:~/opt/gnu/include$ cat algorithm.cc
#include <algorithm>

/home/dave/opt/gnu/gcc/gcc-3.1/bin/g++ -v -E algorithm.cc
...
# 1 "/home/dave/opt/gnu/gcc/gcc-3.1/include/g++-v3/algorithm" 1 3

For some reason the header from /usr/local/include/g++-v3 was not used.
However, if I do the same with a C header, it's loaded from /usr/local/include.
Thus, it appears the search for the v3 headers is special.

In addition,

echo '#include <algorithm>'|/home/dave/opt/gnu/gcc/gcc-3.1/bin/g++ -lang-c++ -v -E -
...
 /home/dave/opt/gnu/gcc/gcc-3.1/lib/gcc-lib/hppa-linux/3.1/cpp0 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -D__hppa__ -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__hppa__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asystem=unix -Asystem=posix -Acpu=hppa -Amachine=hppa -Amachine=bigendian -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_PA_RISC1_1 -
GNU CPP version 3.1 (cpplib) (hppa)
ignoring nonexistent directory "/home/dave/opt/gnu/gcc/gcc-3.1/hppa-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /home/dave/opt/gnu/gcc/gcc-3.1/include
 /home/dave/opt/gnu/gcc/gcc-3.1/lib/gcc-lib/hppa-linux/3.1/include
 /usr/include
End of search list.
<stdin>:1:21: algorithm: No such file or directory

For some reason, cpp0 runs in C mode even though g++ and "-lang-c++" are
specified on the command line.

> >    In that case, we can do without warnings for /usr/local/include
> >    and /opt/gnu.
> 
> I do not see how this follows.  The problems caused by

As discussed, the warnings are about whether the directories are
treated as a system directories or not.  This mainly affects warnings.
These directories are not being fixed and there may be valid
situations where a user would like to reorder the include search
with respect to these two directories.

Removal of the warnings for these directories would appear to resolve
many of the configure problems since the current gettext macros don't
allow reordering /usr/include or /usr/local/include under linux
(I have no idea why linux is special).  There must be some macros
that still add /usr/include but hopefully these are old.

If /usr/local/include isn't removed from the search list in the
situations discussed, then I think we need to allow reordering
and the change to a non-system directory without a warning given
the number of packages which use the gettext macros.  This might
be tightened up in the future.  At the moment, I am ambivalent
as to whether or not these directories need to be treated as system
directories since they are mainly used for site specific installations.

> -I <dir on system path> are not merely because of failure to pick up
> fixincluded headers.  For instance, Dan Jacobowitz points out that
> -I/usr/include can cause havoc when used with a cross compiler; it

I suspect that using "-I/usr/include" must be always wrong unless
"-nostdinc" is used.  Initially, I was against packages attempting
to reorder the gcc search process but enough package authors have
indicated that they don't like the warning and that they want
to be able to reorder the search despite the risks, that I have
second thoughts about it and maybe we should allow them to shoot
themselves in the foot so to speak.

> seems to me that -I/usr/local/include could cause just as much havoc.

Wouldn't be surprised.

> (He wanted these to warn in a cross configuration, which I must
> confess I don't see any way to do - how do we know that
> -I/gltz/quux/include happens to contain headers for the wrong target?

I guess the only way gcc would know would be if there was a mechanism
for a user to build it with a default set of headers for the target.

> My inclination, for the record, is to do nothing until all parties
> come to an agreement on what GCC's behavior _should_ be.  At present,
> I suspect that any patch will be immediately followed by another horde
> of objectors demanding it be put back the way it was.

That's the difficulty with the present situation.  Since the process
is implementation defined, we don't have a standard to fallback on.
We will only make progress on this with clear analysis and a bit of
leadership.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc 3.2's cpp breaks configure scripts

[Miles Bader]

I think /usr/local is well established as `a standard hierarchy that
overrides /usr', and so gcc should _definitely_ search /usr/local/include
before /usr/include -- many people depend on this behavior.

If you have a more complex installation that breaks (e.g., multiple local
versions of gcc installed), it's up to you to figure out a way to fix it, not
the great majority of people that use /usr/local only.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: gcc 3.2's cpp breaks configure scripts

[Daniel Jacobowitz]

On Sat, Aug 03, 2002 at 04:07:07PM -0700, Zack Weinberg wrote:
> I do not see how this follows.  The problems caused by
> -I <dir on system path> are not merely because of failure to pick up
> fixincluded headers.  For instance, Dan Jacobowitz points out that
> -I/usr/include can cause havoc when used with a cross compiler; it
> seems to me that -I/usr/local/include could cause just as much havoc.
> (He wanted these to warn in a cross configuration, which I must
> confess I don't see any way to do - how do we know that
> -I/gltz/quux/include happens to contain headers for the wrong target?

Somewhat tangential to the current discussion, but I was referring
specifically to /usr/include and /usr/local/include, not to any sort of
${prefix}/include (which I always disable in our toolchains anyway; for
historical reasons our ${prefix}/include is where things like the cross
BFD's headers go, not where target headers go.  But that's just a quirk
of our environment.

> My inclination, for the record, is to do nothing until all parties
> come to an agreement on what GCC's behavior _should_ be.  At present,
> I suspect that any patch will be immediately followed by another horde
> of objectors demanding it be put back the way it was.

Absolutely agreed.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: gcc 3.2's cpp breaks configure scripts

[Nix]

On Sun, 11 Aug 2002, John David Anglin mused:
> Jeff,
> 
>> cpp is spitting out a warning about changing the search order of include
>> directories, and this is breaking a _ton_ of configure scripts. I found
>> this when I started rebuilding Mandrake with gcc-3.2 branch.
> 
> You might try the patch below and see if it fixes your problem.  It is a
> variant for gcc-3.2 branch of the patch proposed in this message for the
> main: < http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00708.html >.

Nice :)

> +   This algorithm is quadratic in the number of -I switches, which is
> +   acceptable since there aren't usually that many of them.  */

You could invert it to yield something that was quadratic in the number
of system directories, which might be preferable since the number of
system directories is fixed and may be quite low compared to the silly
number of -I flags used by some programs (look at Evolution build one of
these days); something like

static struct search_path *
remove_dup_nonsys_dirs (pfile, head_ptr, end)
     cpp_reader *pfile;
     struct search_path **head_ptr;
     struct search_path *end;
{
  struct search_path *cur;

  for (cur = *head_ptr; cur != end; cur = cur ? cur->next : *head_ptr)
    if (cur->sysp)
      {
	struct search_path *prev, *other;
        for (other = *head_ptr, prev = NULL; other && other != cur;
             other = other->next)
          {
            if (INO_T_EQ (cur->ino, other->ino)
                && cur->dev == other->dev
                && !(other->sysp))
              {
                other = remove_dup_dir (pfile, prev, head_ptr);
                break;
	      }
            prev = other;
          }
      }

  return prev;
}

(I'm not sure whether the head_ptr manipulation in the outer loop is
needed anymore, and this is utterly untested).

> +system include directories, GCC will ignore the option so that system
> +directories are continued to be processed in the correct order.  This

s/are continued to be/continue to be/

> +Sites that need to install multiple versions of GCC may not want to
> +use the above simple configuration.  It is possible to use the
> +@option{--program-prefix}, @option{--program-suffix} and
> +@option{--program-transform-name} options to install multiple versions
> +into a single directory,

Even though I've done this myself forever, it *is* quite tricky to keep
libstdc++ working for multiple GCC versions in that situation.

(--enable-version-specific-runtime-libs or waiting for GCC 3.3 is the
solution to that, of course.)

-- 
`There's something satisfying about killing JWZ over and over again.'
                                        -- 1i, personal communication

Re: gcc 3.2's cpp breaks configure scripts

[John David Anglin]

Jeff,

> cpp is spitting out a warning about changing the search order of include
> directories, and this is breaking a _ton_ of configure scripts. I found
> this when I started rebuilding Mandrake with gcc-3.2 branch.

You might try the patch below and see if it fixes your problem.  It is a
variant for gcc-3.2 branch of the patch proposed in this message for the
main: < http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00708.html >.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Index: cppinit.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/cppinit.c,v
retrieving revision 1.202.2.5
diff -u -3 -p -r1.202.2.5 cppinit.c
--- cppinit.c	24 May 2002 09:26:48 -0000	1.202.2.5
+++ cppinit.c	10 Aug 2002 04:27:07 -0000
@@ -103,9 +103,13 @@ static void mark_named_operators	PARAMS 
 static void append_include_chain	PARAMS ((cpp_reader *,
 						 char *, int, int));
 static struct search_path * remove_dup_dir	PARAMS ((cpp_reader *,
+						 struct search_path *,
+						 struct search_path **));
+static struct search_path * remove_dup_nonsys_dirs PARAMS ((cpp_reader *,
+						 struct search_path **,
 						 struct search_path *));
 static struct search_path * remove_dup_dirs PARAMS ((cpp_reader *,
-						 struct search_path *));
+						 struct search_path **));
 static void merge_include_chains	PARAMS ((cpp_reader *));
 static bool push_include		PARAMS ((cpp_reader *,
 						 struct pending_option *));
@@ -272,55 +276,86 @@ append_include_chain (pfile, dir, path, 
 }
 
 /* Handle a duplicated include path.  PREV is the link in the chain
-   before the duplicate.  The duplicate is removed from the chain and
-   freed.  Returns PREV.  */
+   before the duplicate, or NULL if the duplicate is at the head of
+   the chain.  The duplicate is removed from the chain and freed.
+   Returns PREV.  */
 static struct search_path *
-remove_dup_dir (pfile, prev)
+remove_dup_dir (pfile, prev, head_ptr)
      cpp_reader *pfile;
      struct search_path *prev;
+     struct search_path **head_ptr;
 {
-  struct search_path *cur = prev->next;
+  struct search_path *cur;
+
+  if (prev != NULL)
+    {
+      cur = prev->next;
+      prev->next = cur->next;
+    }
+  else
+    {
+      cur = *head_ptr;
+      *head_ptr = cur->next;
+    }
 
   if (CPP_OPTION (pfile, verbose))
     fprintf (stderr, _("ignoring duplicate directory \"%s\"\n"), cur->name);
 
-  prev->next = cur->next;
   free ((PTR) cur->name);
   free (cur);
 
   return prev;
 }
 
+/* Remove duplicate non-system directories for which there is an equivalent
+   system directory latter in the chain.  The range for removal is between
+   *HEAD_PTR and END.  Returns the directory before END, or NULL if none.
+   This algorithm is quadratic in the number of -I switches, which is
+   acceptable since there aren't usually that many of them.  */
+static struct search_path *
+remove_dup_nonsys_dirs (pfile, head_ptr, end)
+     cpp_reader *pfile;
+     struct search_path **head_ptr;
+     struct search_path *end;
+{
+  struct search_path *prev = NULL, *cur, *other;
+
+  for (cur = *head_ptr; cur != end; cur = cur ? cur->next : *head_ptr)
+    {
+      if (!cur->sysp)
+	{
+	  for (other = cur->next; other; other = other->next)
+	    if (INO_T_EQ (cur->ino, other->ino)
+		&& cur->dev == other->dev
+		&& other->sysp)
+	      {
+		cur = remove_dup_dir (pfile, prev, head_ptr);
+		break;
+	      }
+	}
+      prev = cur;
+    }
+
+  return prev;
+}
+
 /* Remove duplicate directories from a chain.  Returns the tail of the
    chain, or NULL if the chain is empty.  This algorithm is quadratic
    in the number of -I switches, which is acceptable since there
    aren't usually that many of them.  */
 static struct search_path *
-remove_dup_dirs (pfile, head)
+remove_dup_dirs (pfile, head_ptr)
      cpp_reader *pfile;
-     struct search_path *head;
+     struct search_path **head_ptr;
 {
   struct search_path *prev = NULL, *cur, *other;
 
-  for (cur = head; cur; cur = cur->next)
+  for (cur = *head_ptr; cur; cur = cur->next)
     {
-      for (other = head; other != cur; other = other->next)
-        if (INO_T_EQ (cur->ino, other->ino) && cur->dev == other->dev)
+      for (other = *head_ptr; other != cur; other = other->next)
+	if (INO_T_EQ (cur->ino, other->ino) && cur->dev == other->dev)
 	  {
-	    if (cur->sysp && !other->sysp)
-	      {
-		cpp_warning (pfile,
-			     "changing search order for system directory \"%s\"",
-			     cur->name);
-		if (strcmp (cur->name, other->name))
-		  cpp_warning (pfile, 
-			       "  as it is the same as non-system directory \"%s\"",
-			       other->name);
-		else
-		  cpp_warning (pfile, 
-			       "  as it has already been specified as a non-system directory");
-	      }
-	    cur = remove_dup_dir (pfile, prev);
+	    cur = remove_dup_dir (pfile, prev, head_ptr);
 	    break;
 	  }
       prev = cur;
@@ -358,28 +393,33 @@ merge_include_chains (pfile)
   else
     brack = systm;
 
-  /* This is a bit tricky.  First we drop dupes from the quote-include
-     list.  Then we drop dupes from the bracket-include list.
-     Finally, if qtail and brack are the same directory, we cut out
-     brack and move brack up to point to qtail.
+  /* This is a bit tricky.  First we drop non-system dupes of system
+     directories from the merged bracket-include list.  Next we drop
+     dupes from the bracket and quote include lists.  Then we drop
+     non-system dupes from the merged quote-include list.  Finally,
+     if qtail and brack are the same directory, we cut out brack and
+     move brack up to point to qtail.
 
      We can't just merge the lists and then uniquify them because
      then we may lose directories from the <> search path that should
-     be there; consider -Ifoo -Ibar -I- -Ifoo -Iquux. It is however
+     be there; consider -Ifoo -Ibar -I- -Ifoo -Iquux.  It is however
      safe to treat -Ibar -Ifoo -I- -Ifoo -Iquux as if written
      -Ibar -I- -Ifoo -Iquux.  */
 
-  remove_dup_dirs (pfile, brack);
-  qtail = remove_dup_dirs (pfile, quote);
+  remove_dup_nonsys_dirs (pfile, &brack, NULL);
+  remove_dup_dirs (pfile, &brack);
 
   if (quote)
     {
+      qtail = remove_dup_dirs (pfile, &quote);
       qtail->next = brack;
 
+      qtail = remove_dup_nonsys_dirs (pfile, &quote, brack);
+
       /* If brack == qtail, remove brack as it's simpler.  */
-      if (brack && INO_T_EQ (qtail->ino, brack->ino)
+      if (qtail && brack && INO_T_EQ (qtail->ino, brack->ino)
 	  && qtail->dev == brack->dev)
-	brack = remove_dup_dir (pfile, qtail);
+	brack = remove_dup_dir (pfile, qtail, &quote);
     }
   else
     quote = brack;
Index: doc/install.texi
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.92.2.29
diff -u -3 -p -r1.92.2.29 install.texi
--- doc/install.texi	27 Jun 2002 19:11:31 -0000	1.92.2.29
+++ doc/install.texi	10 Aug 2002 04:27:09 -0000
@@ -464,6 +464,43 @@ any in that directory---are not part of 
 programs---perhaps many others.  (GCC installs its own header files in
 another directory which is based on the @option{--prefix} value.)
 
+Both the local-prefix include directory and the GCC-prefix include
+directory are part of GCC's "system include" directories.  Although these
+two directories are not fixed, they need to be searched in the proper
+order for the correct processing of the include_next directive.  The
+local-prefix include directory is searched before the GCC-prefix
+include directory.  Another characteristic of system include directories
+is that pedantic warnings are turned off for headers in these directories.
+
+Some autoconf macros add @option{-I @var{directory}} options to the
+compiler command line, to ensure that directories containing installed
+packages' headers are searched.  When @var{directory} is one of GCC's
+system include directories, GCC will ignore the option so that system
+directories are continued to be processed in the correct order.  This
+may result in a search order different from what was specified but the
+directory will still be searched.
+
+GCC automatically searches for ordinary libraries using
+@env{GCC_EXEC_PREFIX}.  Thus, when the same installation prefix is
+used for both GCC and packages, GCC will automatically search for
+both headers and libraries.  This provides a configuration that is
+easy to use.  GCC behaves in a manner similar to that when it is
+installed as a system compiler in @file{/usr}.
+
+Sites that need to install multiple versions of GCC may not want to
+use the above simple configuration.  It is possible to use the
+@option{--program-prefix}, @option{--program-suffix} and
+@option{--program-transform-name} options to install multiple versions
+into a single directory, but it may be simpler to use different prefixes
+and the @option{--with-local-prefix} option to specify the location of the
+site-specific files for each version.  It will then be necessary for
+users to specify explicitly the location of local site libraries
+(e.g., with @env{LIBRARY_PATH}).
+
+The same value can be used for both @option{--with-local-prefix} and
+@option{--prefix} provided it is not @file{/usr}.  This can be used
+to avoid the default search of @file{/usr/local/include}.
+
 @strong{Do not} specify @file{/usr} as the @option{--with-local-prefix}!
 The directory you use for @option{--with-local-prefix} @strong{must not}
 contain any of the system's standard header files.  If it did contain

Re: gcc 3.2's cpp breaks configure scripts

[Joe Buck]

Roger Corman writes:
>     It seems somewhat ludicrous that the idea of an option to disable
> the spewing of the message, which breaks a significant number of
> configure scripts, is shunned.  "Let's break lots of code and expect
> everyone else to fix their stuff and not provide any sort of work
> around".  Pretty pathetic.

It does appear to be one of the few gcc warnings that cannot be suppressed
by any means; it will appear unconditionally.  This breakage may be bad
enough that distributors will come up with their own patch, otherwise how
can they hope to put together a distribution with 500 distinct examples of
this breakage.

How about this idea: an option that tells gcc simply to ignore any -I
lines that refer to system directories.  This seems to me to be exactly
what is wanted for gcc command lines generated by configure.  If such an
option existed,

CC="gcc -fignore-system-include-dirs" configure

would work.  The effect of

(csh/tcsh users would type

env CC="gcc -fignore-system-include-dirs" configure

)

Then

gcc -fignore-system-include-dirs -I/usr/include -I/some/place -O2 -c foo.c

would simply be identical to

gcc -I/some/place -O2 -c foo.c

Sure, it's a hack, but it will allow people to build old apps.  The
nice thing about this is that it will avoid the problems that motivated
the warning in the first place, that is, that if the search order for
system directories is changed things like #include_next break and
fixincluded headers can be bypassed.

Re: gcc 3.2's cpp breaks configure scripts

[Roger Corman]

On Thu, Aug 01, 2002 at 02:47:40PM -0700, Joe Buck wrote:
> 
> > > The Right Thing to do is not to add -I/usr/include because that can cause
> > > subtle breakage as well.
> > 
> > Or maybe the right thing is to fix autoconf so that it doesn't think a  
> > warning is a fatal error.
> 
> The problem is that there are very large numbers of GNU and other freeware
> packages out there with this defect in their autoconf files.  When we
> release 3.2, people are going to have a bear of a time building
> distributions.  It will be seen as a gcc problem, even if a good argument
> can be made that it is an autoconf problem.

    It seems somewhat ludicrous that the idea of an option to disable
the spewing of the message, which breaks a significant number of
configure scripts, is shunned.  "Let's break lots of code and expect
everyone else to fix their stuff and not provide any sort of work
around".  Pretty pathetic.

Re: gcc 3.2's cpp breaks configure scripts

[Gareth Pearce]

>
> > > The Right Thing to do is not to add -I/usr/include because that can 
>cause
> > > subtle breakage as well.
> >
> > Or maybe the right thing is to fix autoconf so that it doesn't think a
> > warning is a fatal error.
>
>The problem is that there are very large numbers of GNU and other freeware
>packages out there with this defect in their autoconf files.  When we
>release 3.2, people are going to have a bear of a time building
>distributions.  It will be seen as a gcc problem, even if a good argument
>can be made that it is an autoconf problem.

So now would be a good time to be out pushing for projects to upgrade to 
autoconf 2.5+ (which I am told fixes the problem)?

Having had the situation kindly explained to me in another branch of this 
thread
I see 3 options
1. leave it as is, get out there and push (help even!)
2. drop the warning/enable disablement of warning (last option not liked)
3. add a flag which autoremoves any -I which causes the warning. (doubt this 
is going to go over too well either)
1 = lots of work
2 = back to before with lots of potential breakage...
3 = removes onus to fix the actual problem.

Gareth


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: gcc 3.2's cpp breaks configure scripts

[Joe Buck]

> > The Right Thing to do is not to add -I/usr/include because that can cause
> > subtle breakage as well.
> 
> Or maybe the right thing is to fix autoconf so that it doesn't think a  
> warning is a fatal error.

The problem is that there are very large numbers of GNU and other freeware
packages out there with this defect in their autoconf files.  When we
release 3.2, people are going to have a bear of a time building
distributions.  It will be seen as a gcc problem, even if a good argument
can be made that it is an autoconf problem.

Re: gcc 3.2's cpp breaks configure scripts

[Kevin Handy]

Kai Henningsen wrote:

>matz@suse.de (Michael Matz)  wrote on 31.07.02 in <Pine.LNX.4.33.0207311553070.31138-100000@wotan.suse.de>:
>
>  
>
>>On Wed, 31 Jul 2002, Jan-Benedict Glaw wrote:
>>
>>    
>>
>>>Well... Having used autoconf/automake only _once_ myself, I can tell
>>>that it's quite hard to work with it. I've not really understood its
>>>concepts, I've not really found good/comprehensive documentation.
>>>      
>>>
>>Although this gets OT quickly, autoconf and automake come with extensive
>>documentation in form of info pages.
>>    
>>
>
>Yeah, but those docs are much better as a reference than as a tutorial.  
>IMAO, they are pretty much useless as a tutorial.
>
>And if you look at existing uses, that certainly shows lots and lots of  
>pure cargo-cult programming. I'd say that by far most autoconf users don't  
>understand their tool.
>
>MfG Kai
>  
>

There is a book on autoconf and automake

> http://sources.redhat.com/autobook/

It's a couple of years old though.

Re: gcc 3.2's cpp breaks configure scripts

[Phil Edwards]

On Thu, Aug 01, 2002 at 07:13:39PM +0100, Neil Booth wrote:
> Phil Edwards wrote:-
> > Yes, please.  I'm very annoyed that GCC prints warnings that I cannot disable
> > when I /know/ that they are false or harmless.
> > 
> > I'm wrestling with my development machine at the moment (sysadmin issues),
> > but once it is working again, I will work up such a patch if there is a
> > consensus that it would be worthwhile.  (And if we can agree on option
> > spelling.)
> 
> Please, not more switches.

Fair enough.

> Let's either fix the warning, agree its
> correct, or get rid of it.

Well, you know my opinion.  :-)  I vote for (C).


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: gcc 3.2's cpp breaks configure scripts

[John David Anglin]

> > Turning the warning off is not the correct solution, although there
> > may be some circumstances in which it is emitted when it shouldn't
> > be.
> 
> I think so... but I am probably wrong hehe...

You can display the include search order with "gcc -v -E".  The situation
where gcc emits the message when it shouldn't is when a user include directory
is specified and it is the same as the first directory searched by gcc.
For example,

gcc -v -E main.c -I/opt/gnu/include
...
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/opt/gnu/hppa2.0w-hp-hpux11.00/include"
cpp0: warning: changing search order for system directory "/opt/gnu/include"
cpp0: warning:   as it has already been specified as a non-system directory
ignoring duplicate directory "/opt/gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/gnu/include
 /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include
 /usr/include
End of search list.

As can be seen, the search order hasn't really changed.  If "-I/usr/include"
were added to the command, the search order would really have changed.

These are rules under which the macro lib-prefix.m4 used by configure
in textutils-2.1 adds include directories to CPPFLAGS:

    dnl Potentially add $additional_includedir to $CPPFLAGS.
    dnl But don't add it
    dnl   1. if it's the standard /usr/include,
    dnl   2. if it's already present in $CPPFLAGS,
    dnl   3. if it's /usr/local/include and we are using GCC on Linux,
    dnl   4. if it doesn't exist as a directory.

"/opt/gnu" is my standard prefix.  As can be seen, the above macro
will add "-I/opt/gnu/include" to CPPFLAGS and cause a gcc warning
if something interesting is found there (e.g., libintl.h).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc 3.2's cpp breaks configure scripts

[Neil Booth]

Phil Edwards wrote:-

> On Wed, Jul 31, 2002 at 09:45:39AM -0700, Joe Buck wrote:
> > Just the same, it's a lot to ask the distributors of GNU/Linux and BSD
> > systems to fix every configure script in the world.
> > 
> > Maybe a workaround for the time being is to have a gcc option that
> > suppresses this one warning; people can then write something like
> > 
> > CC="gcc -Wno-check-include-order" ./configure ...
> > 
> > to get around the problem.
> 
> Yes, please.  I'm very annoyed that GCC prints warnings that I cannot disable
> when I /know/ that they are false or harmless.
> 
> I'm wrestling with my development machine at the moment (sysadmin issues),
> but once it is working again, I will work up such a patch if there is a
> consensus that it would be worthwhile.  (And if we can agree on option
> spelling.)

Please, not more switches.  Let's either fix the warning, agree its
correct, or get rid of it.

Neil.

Re: gcc 3.2's cpp breaks configure scripts

[Phil Edwards]

On Wed, Jul 31, 2002 at 09:45:39AM -0700, Joe Buck wrote:
> Just the same, it's a lot to ask the distributors of GNU/Linux and BSD
> systems to fix every configure script in the world.
> 
> Maybe a workaround for the time being is to have a gcc option that
> suppresses this one warning; people can then write something like
> 
> CC="gcc -Wno-check-include-order" ./configure ...
> 
> to get around the problem.

Yes, please.  I'm very annoyed that GCC prints warnings that I cannot disable
when I /know/ that they are false or harmless.

I'm wrestling with my development machine at the moment (sysadmin issues),
but once it is working again, I will work up such a patch if there is a
consensus that it would be worthwhile.  (And if we can agree on option
spelling.)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: gcc 3.2's cpp breaks configure scripts

[Kai Henningsen]

matz@suse.de (Michael Matz)  wrote on 31.07.02 in <Pine.LNX.4.33.0207311553070.31138-100000@wotan.suse.de>:

> On Wed, 31 Jul 2002, Jan-Benedict Glaw wrote:
>
> >
> > Well... Having used autoconf/automake only _once_ myself, I can tell
> > that it's quite hard to work with it. I've not really understood its
> > concepts, I've not really found good/comprehensive documentation.
>
> Although this gets OT quickly, autoconf and automake come with extensive
> documentation in form of info pages.

Yeah, but those docs are much better as a reference than as a tutorial.  
IMAO, they are pretty much useless as a tutorial.

And if you look at existing uses, that certainly shows lots and lots of  
pure cargo-cult programming. I'd say that by far most autoconf users don't  
understand their tool.

MfG Kai

Re: gcc 3.2's cpp breaks configure scripts

[Kai Henningsen]

schwab@suse.de (Andreas Schwab)  wrote on 31.07.02 in <jeheig3uzb.fsf@sykes.suse.de>:

> Jeff Garzik <jgarzik@mandrakesoft.com> writes:
>
> |> cpp is spitting out a warning about changing the search order of include
> |> directories, and this is breaking a _ton_ of configure scripts.  I found
> |> this when I started rebuilding Mandrake with gcc-3.2 branch.
> |>
> |> Just a heads-up, since I'm too slack to file a formal bug report :) This
> |> is particularly subtle breakage sometimes, because sometimes the
> |> configure step will succeed, but the build will break, or lack features,
> |> due to the lack of HAVE_FOO_H defines.
>
> The Right Thing to do is not to add -I/usr/include because that can cause
> subtle breakage as well.

Or maybe the right thing is to fix autoconf so that it doesn't think a  
warning is a fatal error.

I'd consider that a pretty serious (and really inexcusable) autoconf bug.

MfG Kai

Re: gcc 3.2's cpp breaks configure scripts

[Jakub Jelinek]

On Thu, Aug 01, 2002 at 07:15:39AM +0000, Gareth Pearce wrote:
> Hmmm I think the lights starting to seep into my brain...  But just to be 
> sure,
> your saying that adding -I/usr/include (or similar) can cause libstdc++ 
> headers to break due to the way they use #include_next?

Yes.

	Jakub

Re: gcc 3.2's cpp breaks configure scripts

[Gareth Pearce]

>
>On Thu, Aug 01, 2002 at 07:03:43AM +0000, Gareth Pearce wrote:
> > but only with files which are fixincluded right? (not rhetorical)
>
>This has nothing to do with fixinclude. #include_next is used e.g.
>to include gcc's include header of the same name, or by libstdc++-v3
>headers to include C headers, etc.
>Also, -I/usr/include changes the status of /usr/include headers from
>system headers to user headers, thus you may get warnings (or errors
>with -Werror) where you otherwise would not get any.


Hmmm I think the lights starting to seep into my brain...  But just to be 
sure,
your saying that adding -I/usr/include (or similar) can cause libstdc++ 
headers to break due to the way they use #include_next?  If so then I guess 
its the rough road or no road...(too many special cases for my liking)  hmmm 
time to bug someone else then I guess :)

Gareth

_________________________________________________________________
Join the worldÂ’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Re: gcc 3.2's cpp breaks configure scripts

[Jakub Jelinek]

On Thu, Aug 01, 2002 at 07:03:43AM +0000, Gareth Pearce wrote:
> but only with files which are fixincluded right? (not rhetorical)

This has nothing to do with fixinclude. #include_next is used e.g.
to include gcc's include header of the same name, or by libstdc++-v3
headers to include C headers, etc.
Also, -I/usr/include changes the status of /usr/include headers from
system headers to user headers, thus you may get warnings (or errors
with -Werror) where you otherwise would not get any.

	Jakub

Re: gcc 3.2's cpp breaks configure scripts

[Gareth Pearce]

> >
> > Hmm, I see, changed order (expected) - and gcc's syslimits not being 
>called,
> > but that seems okay since limits is already called... (ie it looks like 
>the
> > copy of linux I am looking at at least has been designed to handle this
> > situation) *shrug*
> > I see the possibility of breakage... not from the #include_next though. 
>(ie,
> > less potential breakage then if the #include_next wasnt there)
>
>limits.h with -I/usr/include was actually broken already twice
>in the history if I remember well and in both times changed after a while
>so that it works, though it is quite ugly. This is not the case with
>/usr/include/c++/<version> though and the more headers use #include_next
>this means more (potential) problems.

but only with files which are fixincluded right? (not rhetorical)
So possibly the mandatoryness of the warning could persist for just 
fixincluded headers not being chosen due to -I<dir> and be optional 
otherwise?  Or is it a case of make the transition to better pastures a 
rough road so that people travel faster - being considered more important.

Gareth


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: gcc 3.2's cpp breaks configure scripts

[Gareth Pearce]

>
> > > cpp is spitting out a warning about changing the search order of 
>include
> > > directories, and this is breaking a _ton_ of configure scripts.  I 
>found
> > > this when I started rebuilding Mandrake with gcc-3.2 branch.
>
>Gareth Pearce writes:
> > This, from what little i have seen, seems to be due to the fact that 
>many
> > configure scripts segments are extremely overly picky.  They take any 
>output
> > at all as to mean that its failed.  Really it should seem to me that 
>they
> > should be looking for errors, or specific warnings rather then just 
>anything
> > at all.
>
>Just the same, it's a lot to ask the distributors of GNU/Linux and BSD
>systems to fix every configure script in the world.

Indeed it would be, but prehaps this should be suggested to the autoconf 
people for future versions?
>
>Maybe a workaround for the time being is to have a gcc option that
>suppresses this one warning; people can then write something like
>
>CC="gcc -Wno-check-include-order" ./configure ...
>
>to get around the problem.
>
>However, if this warning appears, it is likely that the programs in
>question won't build properly on OSes that ship bad C headers, that have
>to be fixed by fixincludes.  In that case, it may well be that the gcc
>command lines will wind up with something like -I/usr/include which means
>that the fixed headers will get bypassed.

Yes, would seem (to me at least) a database of where the fixincluded headers 
came from would allow gcc to substitute them back in when you pass a -I like 
that. (I dont see any significant performance issue, is there possibility 
that people Really want to overide the fixincludes? - in which case there 
could be a -fallow-fixincludes-overide?).
(Also, last time i checked gcc produces that warning for Any directories 
which are considered internal, rather than Just the direectories where the 
fixincluded headers came from! - I compile gcc with --prefix=$HOME on my OSF 
alpha box since i dont have priviledges for /usr or /usr/local - and even 
though, all the headers in my home directory are entirely from application 
install, $HOME/include was the biggest cause of warnings i experienced. - I 
havent compiled much with my latest gcc cvs version yet so maybe that has 
changed.)

Idealy in my mind - autoconf would make configure scripts that Warn users if 
such warnings turned up, but ignore them otherwise.

However, I am a humble user, my opinions are from a very limited sphere of 
use.

Gareth

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: gcc 3.2's cpp breaks configure scripts

[Joe Buck]

> > cpp is spitting out a warning about changing the search order of include
> > directories, and this is breaking a _ton_ of configure scripts.  I found
> > this when I started rebuilding Mandrake with gcc-3.2 branch.

Gareth Pearce writes:
> This, from what little i have seen, seems to be due to the fact that many
> configure scripts segments are extremely overly picky.  They take any output
> at all as to mean that its failed.  Really it should seem to me that they
> should be looking for errors, or specific warnings rather then just anything
> at all.

Just the same, it's a lot to ask the distributors of GNU/Linux and BSD
systems to fix every configure script in the world.

Maybe a workaround for the time being is to have a gcc option that
suppresses this one warning; people can then write something like

CC="gcc -Wno-check-include-order" ./configure ...

to get around the problem.

However, if this warning appears, it is likely that the programs in
question won't build properly on OSes that ship bad C headers, that have
to be fixed by fixincludes.  In that case, it may well be that the gcc
command lines will wind up with something like -I/usr/include which means
that the fixed headers will get bypassed.

Re: gcc 3.2's cpp breaks configure scripts

[Michael Matz]

Hi,

On Wed, 31 Jul 2002, Jan-Benedict Glaw wrote:

>
> Well... Having used autoconf/automake only _once_ myself, I can tell
> that it's quite hard to work with it. I've not really understood its
> concepts, I've not really found good/comprehensive documentation.

Although this gets OT quickly, autoconf and automake come with extensive
documentation in form of info pages.


Ciao,
Michael.

Re: gcc 3.2's cpp breaks configure scripts

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Wed, 2002-07-31 09:24:26 -0400, Jeff Garzik <jgarzik@mandrakesoft.com>
wrote in message <3D47E50A.2030004@mandrakesoft.com>:
> Andreas Schwab wrote:
> >Jeff Garzik <jgarzik@mandrakesoft.com> writes:
[...]
> Unfortunately this leaves a lot of minor packages out there set up by 
> people not so familiar with configure.

Well... Having used autoconf/automake only _once_ myself, I can tell
that it's quite hard to work with it. I've not really understood its
concepts, I've not really found good/comprehensive documentation.

Even a _mentioned_ script helping to get the beginning right wasn't
exactly easy to find. If there was more documentation available showing
experienced programmers (and Makefile writers) how to use it would be
an enormeous advantage...

So for these days, I only use the './configure' part of it, no real clue
of how to create all the macros around it...

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: gcc 3.2's cpp breaks configure scripts

[Jeff Garzik]

Andreas Schwab wrote:
> Jeff Garzik <jgarzik@mandrakesoft.com> writes:
> 
> |> cpp is spitting out a warning about changing the search order of include
> |> directories, and this is breaking a _ton_ of configure scripts.  I found
> |> this when I started rebuilding Mandrake with gcc-3.2 branch.
> |> 
> |> Just a heads-up, since I'm too slack to file a formal bug report :) This
> |> is particularly subtle breakage sometimes, because sometimes the configure
> |> step will succeed, but the build will break, or lack features, due to the
> |> lack of HAVE_FOO_H defines.
> 
> The Right Thing to do is not to add -I/usr/include because that can cause
> subtle breakage as well.


Oh, agreed.  And most of the major packages, KDE and GNOME and basic GNU 
tools, get it right.  They've been doing configure scripts for a while, 
and have a clue.

Unfortunately this leaves a lot of minor packages out there set up by 
people not so familiar with configure.

Oh well :)

	Jeff

Re: gcc 3.2's cpp breaks configure scripts

[Andreas Schwab]

Jeff Garzik <jgarzik@mandrakesoft.com> writes:

|> cpp is spitting out a warning about changing the search order of include
|> directories, and this is breaking a _ton_ of configure scripts.  I found
|> this when I started rebuilding Mandrake with gcc-3.2 branch.
|> 
|> Just a heads-up, since I'm too slack to file a formal bug report :) This
|> is particularly subtle breakage sometimes, because sometimes the configure
|> step will succeed, but the build will break, or lack features, due to the
|> lack of HAVE_FOO_H defines.

The Right Thing to do is not to add -I/usr/include because that can cause
subtle breakage as well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc 3.2's cpp breaks configure scripts

[Gareth Pearce]

----- Original Message -----
From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
To: <gcc@gcc.gnu.org>
Sent: Wednesday, July 31, 2002 10:22 PM
Subject: gcc 3.2's cpp breaks configure scripts


> cpp is spitting out a warning about changing the search order of include
> directories, and this is breaking a _ton_ of configure scripts.  I found
> this when I started rebuilding Mandrake with gcc-3.2 branch.
>
This, from what little i have seen, seems to be due to the fact that many
configure scripts segments are extremely overly picky.  They take any output
at all as to mean that its failed.  Really it should seem to me that they
should be looking for errors, or specific warnings rather then just anything
at all.  However this would take more effort on the configure scripts part
and maybe even slow them down even more... Prehaps there needs to be a
compiler error/warning standard :P

Gareth

gcc 3.2's cpp breaks configure scripts

[Jeff Garzik]

cpp is spitting out a warning about changing the search order of include 
directories, and this is breaking a _ton_ of configure scripts.  I found 
this when I started rebuilding Mandrake with gcc-3.2 branch.

Just a heads-up, since I'm too slack to file a formal bug report :) 
This is particularly subtle breakage sometimes, because sometimes the 
configure step will succeed, but the build will break, or lack features, 
due to the lack of HAVE_FOO_H defines.

Usually the

Example from htdig's config.log:
[...snip...]
configure:3197: checking for zlib.h
configure:3207: gcc -E  -I/usr/include conftest.c >/dev/null 2>conftest.out
cpp0: warning: changing search order for system directory "/usr/include"
cpp0: warning:   as it has already been specified as a non-system directory
configure: failed program was:
#line 3202 "configure"
#include "confdefs.h"
#include <zlib.h>
[...snip...]



Example from lynx's config.log:
[...snip...]
configure:8814: checking for fcntl.h
configure:8824: gcc -E  -I../intl -D_GNU_SOURCE  -DLINUX -I/usr/include 
conftest
.c >/dev/null 2>conftest.out
cpp0: warning: changing search order for system directory "/usr/include"
cpp0: warning:   as it has already been specified as a non-system directory
configure: failed program was:
#line 8819 "configure"
#include "confdefs.h"
#include <fcntl.h>
[...snip...]



gcc version info:
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib 
--with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info 
--enable-shared --enable-threads=posix --disable-checking 
--enable-long-long --enable-__cxa_atexit 
--enable-languages=c,c++,ada,f77,objc,java 
--host=i586-mandrake-linux-gnu --with-system-zlib --with-cpu=athlon
Thread model: posix
gcc version 3.2 (Mandrake Linux 9.0 3.2-0.2mdk)