This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: #include_next and removing of duplicate include dirs
- To: Jakub Jelinek <jakub at redhat dot com>
- Subject: Re: #include_next and removing of duplicate include dirs
- From: Zack Weinberg <zackw at panix dot com>
- Date: Mon, 3 Sep 2001 12:16:25 -0400
- Cc: Neil Booth <neil at daikokuya dot demon dot co dot uk>,Benjamin Kosnik <bkoz at redhat dot com>, 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> <20010903080133.Y25384@devserv.devel.redhat.com>
On Mon, Sep 03, 2001 at 08:01:33AM -0400, Jakub Jelinek wrote:
> 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):
No. The bug is either in the code that set COMPILER_PATH in the
first place, or the code that is using #include_next in the first
place. In fact, I will bet you that neither is actually necessary.
-frepo ought to preserve the user's -I switches, but no more, and
it ought to hand them back to the compiler as -I switches.
A header named <std_cstddef.h> should be able to say simply
#include <stddef.h>. If that gets the wrong <stddef.h>, then we
need to look at why libstdc++ needs to replace <stddef.h> in the
first place. You are only asking for endless nightmares creating
headers with the same names as the libc headers.
zw