This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
#include_next and removing of duplicate include dirs
- To: Neil Booth <neil at daikokuya dot demon dot co dot uk>, Zack Weinberg <zackw at panix dot com>, Benjamin Kosnik <bkoz at redhat dot com>
- Subject: #include_next and removing of duplicate include dirs
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Mon, 3 Sep 2001 08:01:33 -0400
- Cc: gcc at gcc dot gnu dot org
- References: <20010902143200.N550@sunsite.ms.mff.cuni.cz> <Pine.SOL.3.91.1010902100805.27154A-100000@taarna.cygnus.com>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
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