This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

#include_next and removing of duplicate include dirs


On Sun, Sep 02, 2001 at 10:14:04AM -0700, Benjamin Kosnik wrote:
> Jakub, I think this is because a third set of includes is also necessary, 
> but not yet present in include/*. These are the c_compatibilty inclues, 
> and are the C++ versions of things like stdio.h, ctype.h, etc. 

Then I think the bug is in cpplib, particularly that remove_dup_dirs is
not a safe optimization in presence of #include_next.
Below is just a simplified testcase for what is going during -frepo
(the second invocation is done from within collect2 and COMPILER_PATH is set
there to a list of paths, but it is enough to put just the cc1plus 3.0.2 location
in):

$ echo '#include <iostream>' > test.C
$ g++3 -c test.C -v
...
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/g++-v3
 /usr/include/g++-v3/i386-redhat-linux
 /usr/include/g++-v3/backward
 /usr/lib/gcc-lib/i386-redhat-linux/3.0.2/include
 /usr/include
...
# compilation succeeds...
$ COMPILER_PATH=/usr/lib/gcc-lib/i386-redhat-linux/3.0.2/ g++3 -c test.C -v
...
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/i386-redhat-linux/include"
ignoring duplicate directory
"/usr/lib/gcc-lib/i386-redhat-linux/3.0.2/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-lib/i386-redhat-linux/3.0.2/include
 /usr/include/g++-v3
 /usr/include/g++-v3/i386-redhat-linux
 /usr/include/g++-v3/backward
 /usr/include
End of search list.
In file included from /usr/include/g++-v3/bits/std_cstdio.h:38,
                 from /usr/include/g++-v3/cstdio:31,
                 from /usr/include/g++-v3/i386-redhat-linux/bits/c++io.h:35,
                 from /usr/include/g++-v3/bits/fpos.h:39,
                 from /usr/include/g++-v3/bits/std_iosfwd.h:41,
                 from /usr/include/g++-v3/bits/std_ios.h:39,
                 from /usr/include/g++-v3/bits/std_ostream.h:39,
                 from /usr/include/g++-v3/bits/std_iostream.h:40,
                 from /usr/include/g++-v3/iostream:31,
                 from test.C:1:
/usr/include/g++-v3/bits/std_cstddef.h:38:25: stddef.h: No such file or directory
...
# compilation fails

So, IMHO cppinit.c(remove_dup_dirs) should either only remove duplicates if
they immediately follow each other, or keep 2 different search paths, one
smaller with all dups removed, one bigger with either no dups or only dups
immediately following each other removed. The latter would be used only for
#include_next.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]