libstdc++/6720: compile error using stl extensions

[John Blinka]

paolo@gcc.gnu.org wrote:
> 
> Synopsis: compile error using stl extensions
> 
> Responsible-Changed-From-To: unassigned->paolo
> Responsible-Changed-By: paolo
> Responsible-Changed-When: Sun May 19 07:56:59 2002
> Responsible-Changed-Why:
>     Triaged.
> State-Changed-From-To: open->feedback
> State-Changed-By: paolo
> State-Changed-When: Sun May 19 07:56:59 2002
> State-Changed-Why:
>     Does changing -I to -idirafter solve the problem for you? E.g.:
>     g++ -o a -idirafter/usr/local/lang/gcc/include/g++-v3/ext a.cc

Yes. -dirafter solves the problem (in all the cases I reported).  Thanks
for the "fix".

> 
>     Thanks for your report, Paolo.
> 
>     P.S. Notice that, from the manual: "... It is dangerous to specify a standard system include directory in -I option. This defeats the special treatment of system headers."

Thanks for pointing this out.  This appears to be a change from
gcc-3.0.4 to gcc-3.1.
I gather that this new interpretation is required by the current manner
in which
gcc-3.1 fixes system headers.  But it introduces an awkward status for
the stl
extension classes.  There are 2 manifestations of this awkwardness:

1)  One can include them with

    #include <ext/extension_class>

    and compile without using either -I or -idirafter, or

2)  When using a header defined by the C++ standard and an extension
class, one can include
    them with

    #include <C++ standard class>
    #include <extension_class>

    and use -idirafter/path_to_stl_extension_classes, and make sure
*not* to use
    -I/path_to_stl_extension_classes.

The #include <ext/extension class> solution gives the stl extension
classes a
special status - they're the only classes which need a relative path in
#include.
The -idirafter solution (and the failure of the -I solution) rubs
against decades
of use of -I to solve such problems.  The problem is that the stl
extension classes
are located in a "standard system include directory" but the system
doesn't look
in that directory!   Why not?

Thanks for your help and your gentle recommendation to read the manual.

John Blinka