Re: libstdc++/6720: compile error using stl extensions

[John Blinka <jblinka@neo.rr.com>]

The following reply was made to PR libstdc++/6720; it has been noted by GNATS.

From: John Blinka <jblinka@neo.rr.com>
To: paolo@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/6720: compile error using stl extensions
Date: Mon, 20 May 2002 08:05:17 -0400

 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