g++-3.0 vs. kdelibs-2.1.2

[Franz Sirl]

At 12:19 21.06.2001, Adam J. Richter wrote:
>         This may be a gcc-3.0 bug or it may be a kdelibs-2.1.2 bug.
>I am running Linux 2.4.5, gcc 3.0, glibc 2.2.3, and kdelibs 2.1.2
>
>         If I create a C++ file, foo.cc, consisting only of the single
>line "#include <vector>", then "g++ -c foo.cc" works fine, but
>"g++ -I/usr/include -c foo.cc" results in compilation failure,
>beginning with:
>
>In file included from /usr/include/g++-v3/bits/stl_algobase.h:42,
>                  from /usr/include/g++-v3/bits/std_vector.h:33,
>                  from /usr/include/g++-v3/vector:31,
>                  from foo.cc:1:
>/usr/include/g++-v3/bits/std_cstring.h:40:25: string.h: No such file or 
>directory
>
>         Lines 34-40 of /usr/include/g++-v3/bits/std_cstring.h are:
>#ifndef _CPP_CSTRING
>#define _CPP_CSTRING 1
>
>#include <bits/std_cstddef.h>
>
>#pragma GCC system_header
>#include_next <string.h>
>
>
>         I thought that adding "-I<directory>" argument to the compiler
>could not cause a #include_next that succeeded without the flag to
>fail (i.e., I would think that adding more directories to the search
>path should not cause #include_next to fail).  So, this may be a C
>preprocessor bug, or it may be my lack of understanding of this GNU
>extension to cpp.
>
>         If this is correct behavior for cpp, then this is also a
>kdelibs bug, because kdelibs-2.1.2/arts/mcop{,idl}/ has this problem
>if kdelibs is built with --prefix=/usr (making KDE_INCLUDES "-I/usr/include").

This is a bug in kdelibs, I fixed it by filtering out /usr/include in (I 
think) admin/acinclude.m4 in the same way some other directories are 
filtered out. I can send you the patch in a few hours when I'm home again.

Franz.