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

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

[Gabriel Dos Reis]

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

From: Gabriel Dos Reis <gdr@codesourcery.com>
To: John Blinka <jblinka@neo.rr.com>
Cc: paolo@gcc.gnu.org, gcc-gnats@gcc.gnu.org, neil@gcc.gnu.org
Subject: Re: libstdc++/6720: compile error using stl extensions
Date: 20 May 2002 19:46:33 +0200

 John Blinka <jblinka@neo.rr.com> writes:
 
 [...]
 
 |  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?
 
 What you're observing is an instance of a much more general problem
 with the way GCC handles standard headers implemented and files.
 If you compile the following
 
    % cat t.C
    #include <cmath>
    int main()
    {
       double x = std::sin(9.6);
    }
 
 with g++ -I. t.C and you happen to have a file named cmath in the
 current directory, then you get into troubles.  That is a defect in
 GCC. The meaning of <cmath> is well-defined and GCC/g++ shouldn't get
 into trouble because of the switch I.  
 
 A way to cure that is to teach the (now integrated) CPP that some
 headers have special meanings within the language, and the CPP should
 map them into a robust maner, irrespective of what the surrounding
 environment is.  Obviously, that implies there should be a flag to
 control that behaviour, say --no-standard-headers to tell CPP that it
 should not lookup standard headers in a special way.
 
 -- Gaby

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

[paolo]

Synopsis: compile error using stl extensions

State-Changed-From-To: feedback->closed
State-Changed-By: paolo
State-Changed-When: Thu Oct 31 13:18:44 2002
State-Changed-Why:
    I think we can close it.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6720

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

[Phil Edwards]

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

From: Phil Edwards <phil@jaj.com>
To: John Blinka <jblinka@neo.rr.com>
Cc: paolo@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/6720: compile error using stl extensions
Date: Mon, 20 May 2002 13:46:02 -0400

 On Mon, May 20, 2002 at 08:05:17AM -0400, John Blinka wrote:
 > 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.
 
 They're no different from <sys/stat.h> or <X11/Xlib.h> or <net/if.h>.
 
 -- 
 If ye love wealth greater than liberty, the tranquility of servitude greater
 than the animating contest for freedom, go home and leave us in peace.  We seek
 not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
 and may posterity forget that ye were our countrymen.            - Samuel Adams

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

[John Blinka]

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

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

[paolo]

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
    
    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."

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6720