Re: gcc 3.2's cpp breaks configure scripts

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> 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)