This hits when compiling rrdtools, which creates a perl .xs module. It's
and autoconf package, and hence has a config.h. perl also has a config.h
used from it's headers (by doing a 'include "config.h"', so the one from the
perl include dir is used correctly), which has a multiple include guard.
Once the perl config.h is included the source goes on, and tries to include
it's own config.h. There is no way anymore due to the bug.
It tries to do this with '#include <config.h>', i.e. just searching the -I
paths (which are setup correctly, so it could find it in ../config.h).
But this doesn't work anymore (it did with 3.3.x), as somehow it seems that
the place of config.h as it first was found is cached (the perl one), and then
the ../config.h one isn't even tried. To demonstrate this I've put a tarball
below. After unpacking, please do:
% cd a
% find -type f
./b/header.h
./b/inc-b.h
./c/inc.c
./header.h
% cd c
% gcc-4 -E -I .. -I ../b inc.c
# 1 "inc.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "inc.c"
# 1 "../b/inc-b.h" 1
# 1 "../b/header.h" 1
B
# 1 "../b/inc-b.h" 2
# 2 "inc.c" 2
Note how the two include directives in inc.c have no effect, _although_
-I .. is before -I ../b in the cmdline. gcc 3 does it correctly:
% gcc-3 -E -I .. -I ../b inc.c | grep header.h
# 1 "inc.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "inc.c"
# 1 "../b/inc-b.h" 1
# 1 "../b/header.h" 1
B
# 2 "../b/inc-b.h" 2
# 2 "inc.c" 2
# 1 "../header.h" 1
A
# 3 "inc.c" 2
# 1 "../header.h" 1
A
# 4 "inc.c" 2
--
Summary: libcpp incorrectly handles different headers with same
name
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21039
