This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/6720: compile error using stl extensions
- From: John Blinka <jblinka at neo dot rr dot com>
- To: paolo at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
- Date: Mon, 20 May 2002 08:05:17 -0400
- Subject: Re: libstdc++/6720: compile error using stl extensions
- References: <20020519145700.4431.qmail@sources.redhat.com>
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