public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/6720: compile error using stl extensions
@ 2002-05-20 10:56 Phil Edwards
0 siblings, 0 replies; 5+ messages in thread
From: Phil Edwards @ 2002-05-20 10:56 UTC (permalink / raw)
To: paolo; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libstdc++/6720: compile error using stl extensions
@ 2002-10-31 13:18 paolo
0 siblings, 0 replies; 5+ messages in thread
From: paolo @ 2002-10-31 13:18 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, jblinka, 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libstdc++/6720: compile error using stl extensions
@ 2002-05-20 10:56 Gabriel Dos Reis
0 siblings, 0 replies; 5+ messages in thread
From: Gabriel Dos Reis @ 2002-05-20 10:56 UTC (permalink / raw)
To: paolo; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libstdc++/6720: compile error using stl extensions
@ 2002-05-20 5:06 John Blinka
0 siblings, 0 replies; 5+ messages in thread
From: John Blinka @ 2002-05-20 5:06 UTC (permalink / raw)
To: paolo; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libstdc++/6720: compile error using stl extensions
@ 2002-05-19 7:57 paolo
0 siblings, 0 replies; 5+ messages in thread
From: paolo @ 2002-05-19 7:57 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, jblinka, nobody, 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-10-31 21:18 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-05-20 10:56 libstdc++/6720: compile error using stl extensions Phil Edwards
-- strict thread matches above, loose matches on Subject: below --
2002-10-31 13:18 paolo
2002-05-20 10:56 Gabriel Dos Reis
2002-05-20 5:06 John Blinka
2002-05-19 7:57 paolo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).