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 _______________________________________________ Bug-textutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-textutils
