public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/6998: failure when #include <fstream>
@ 2002-06-11 15:36 Phil Edwards
0 siblings, 0 replies; 8+ messages in thread
From: Phil Edwards @ 2002-06-11 15:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR libstdc++/6998; it has been noted by GNATS.
From: Phil Edwards <phil@jaj.com>
To: Jerry Pendergraft <jerry@endocardial.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/6998: failure when #include <fstream>
Date: Tue, 11 Jun 2002 18:29:59 -0400
On Tue, Jun 11, 2002 at 05:09:17PM -0500, Jerry Pendergraft wrote:
> Yes there was - gcc-3.0.1.
> The fact that the message was different than the remark in the FAQ is what
> made me miss it the first time.
Yeah, that is kind of odd. (Was the 3.0.1 configured with default arguments,
out of curiosity?)
> Would that also explain why I was never able to build libstdc++-v3 with
> configuring with --enable-cheaders=(c|c_shadow) ?
Doubtful; the cheaders issues usually don't depend on anything already
in $prefix. What's more, the cheaders situation itself is twisted. :-)
> Perhaps configure could check for the previous version condition and warn
> the user?
The reason this was never done before is that a previous installation of
an earlier version can look an awful lot like a previous installation of
the same version, i.e., running "make install; make install" shouldn't
fail the second time.
The proper solution is to do for the C++ headers what we've done all along
for other parts of the compiler, and install them in a directory containing
the version number. Work on this is already happening.
Phil
--
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] 8+ messages in thread
* Re: libstdc++/6998: failure when #include <fstream>
@ 2002-07-03 9:20 bkoz
0 siblings, 0 replies; 8+ messages in thread
From: bkoz @ 2002-07-03 9:20 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, jerry, nobody, pme
Synopsis: failure when #include <fstream>
Responsible-Changed-From-To: unassigned->pme
Responsible-Changed-By: bkoz
Responsible-Changed-When: Wed Jul 3 09:20:32 2002
Responsible-Changed-Why:
Seems like you've been handling this...
State-Changed-From-To: open->closed
State-Changed-By: bkoz
State-Changed-When: Wed Jul 3 09:20:32 2002
State-Changed-Why:
I think this issue is now resolved. At this point, both gcc-3.1.1 and gcc-3.2.0 will have versioned C++ includes, preventing this kind of problem from happening in the future.
Sorry this happened with the 3.1.0 release.
-benjamin
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6998
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libstdc++/6998: failure when #include <fstream>
@ 2002-06-11 16:26 Phil Edwards
0 siblings, 0 replies; 8+ messages in thread
From: Phil Edwards @ 2002-06-11 16:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR libstdc++/6998; it has been noted by GNATS.
From: Phil Edwards <phil@jaj.com>
To: Jerry Pendergraft <jerry@endocardial.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/6998: failure when #include <fstream>
Date: Tue, 11 Jun 2002 19:20:41 -0400
On Tue, Jun 11, 2002 at 06:07:59PM -0500, Jerry Pendergraft wrote:
> Oh - by the way could you tell me a little about which libstdc++-v3 to use.
> The install page for libstdc++-v3 tells me to trash the one that comes
> with gcc-3.1 and use their latest snapshot. But that .x.97 appears to be
> older than the one in the 3.1 distribution?
Yes, you should use the one that comes with 3.1. The 3.0.97 snapshot
should only replace a 3.0 GCC.
--
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] 8+ messages in thread
* Re: libstdc++/6998: failure when #include <fstream>
@ 2002-06-11 16:16 Jerry Pendergraft
0 siblings, 0 replies; 8+ messages in thread
From: Jerry Pendergraft @ 2002-06-11 16:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR libstdc++/6998; it has been noted by GNATS.
From: Jerry Pendergraft <jerry@endocardial.com>
To: Phil Edwards <phil@jaj.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/6998: failure when #include <fstream>
Date: Tue, 11 Jun 2002 18:07:59 -0500 (CDT)
Oh - by the way could you tell me a little about which libstdc++-v3 to use.
The install page for libstdc++-v3 tells me to trash the one that comes
with gcc-3.1 and use their latest snapshot. But that .x.97 appears to be
older than the one in the 3.1 distribution?
Which is correct?
--
Jerry Pendergraft jerry.pendergraft@endocardial.com
Endocardial Solutions voice: 651-523-6935
1350 Energy Lane, Suite 110 fax: 651-644-7897
St Paul, MN 55108-5254
On Tue, 11 Jun 2002, Phil Edwards wrote:
> On Tue, Jun 11, 2002 at 05:09:17PM -0500, Jerry Pendergraft wrote:
> > Yes there was - gcc-3.0.1.
> > The fact that the message was different than the remark in the FAQ is what
> > made me miss it the first time.
>
> Yeah, that is kind of odd. (Was the 3.0.1 configured with default arguments,
> out of curiosity?)
>
> > Would that also explain why I was never able to build libstdc++-v3 with
> > configuring with --enable-cheaders=(c|c_shadow) ?
>
> Doubtful; the cheaders issues usually don't depend on anything already
> in $prefix. What's more, the cheaders situation itself is twisted. :-)
>
> > Perhaps configure could check for the previous version condition and warn
> > the user?
>
> The reason this was never done before is that a previous installation of
> an earlier version can look an awful lot like a previous installation of
> the same version, i.e., running "make install; make install" shouldn't
> fail the second time.
>
> The proper solution is to do for the C++ headers what we've done all along
> for other parts of the compiler, and install them in a directory containing
> the version number. Work on this is already happening.
>
>
> Phil
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libstdc++/6998: failure when #include <fstream>
@ 2002-06-11 15:36 Jerry Pendergraft
0 siblings, 0 replies; 8+ messages in thread
From: Jerry Pendergraft @ 2002-06-11 15:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR libstdc++/6998; it has been noted by GNATS.
From: Jerry Pendergraft <jerry@endocardial.com>
To: Phil Edwards <phil@jaj.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/6998: failure when #include <fstream>
Date: Tue, 11 Jun 2002 17:35:34 -0500 (CDT)
On Tue, 11 Jun 2002, Phil Edwards wrote:
> On Tue, Jun 11, 2002 at 05:09:17PM -0500, Jerry Pendergraft wrote:
> > Yes there was - gcc-3.0.1.
> > The fact that the message was different than the remark in the FAQ is what
> > made me miss it the first time.
>
> Yeah, that is kind of odd. (Was the 3.0.1 configured with default arguments,
> out of curiosity?)
Yep - at least during a couple of the more than a dozen cycles of
make distclean, configure ;^)
Actually the only non defaults I ever used were:
--disable-shared
Come to think of it, I may have always used that one.
And then I tried --enable-cheaders=c and --enable-cheaders=c_shadow
Worth noting also, I tried all this on Solaris 5.8 with the same results.
>
> > Would that also explain why I was never able to build libstdc++-v3 with
> > configuring with --enable-cheaders=(c|c_shadow) ?
>
> Doubtful; the cheaders issues usually don't depend on anything already
> in $prefix. What's more, the cheaders situation itself is twisted. :-)
>
> > Perhaps configure could check for the previous version condition and warn
> > the user?
>
> The reason this was never done before is that a previous installation of
> an earlier version can look an awful lot like a previous installation of
> the same version, i.e., running "make install; make install" shouldn't
> fail the second time.
>
> The proper solution is to do for the C++ headers what we've done all along
> for other parts of the compiler, and install them in a directory containing
> the version number. Work on this is already happening.
>
>
> Phil
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libstdc++/6998: failure when #include <fstream>
@ 2002-06-11 15:16 Jerry Pendergraft
0 siblings, 0 replies; 8+ messages in thread
From: Jerry Pendergraft @ 2002-06-11 15:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR libstdc++/6998; it has been noted by GNATS.
From: Jerry Pendergraft <jerry@endocardial.com>
To: Phil Edwards <phil@jaj.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/6998: failure when #include <fstream>
Date: Tue, 11 Jun 2002 17:09:17 -0500 (CDT)
Yes there was - gcc-3.0.1.
The fact that the message was different than the remark in the FAQ is what
made me miss it the first time.
Would that also explain why I was never able to build libstdc++-v3 with
configuring with --enable-cheaders=(c|c_shadow) ?
I am going to clean everything out tonight and re-bootstrap it.
Perhaps configure could check for the previous version condition and warn
the user?
Thanks,
--
Jerry Pendergraft jerry.pendergraft@endocardial.com
Endocardial Solutions voice: 651-523-6935
1350 Energy Lane, Suite 110 fax: 651-644-7897
St Paul, MN 55108-5254
On Tue, 11 Jun 2002, Phil Edwards wrote:
> On Tue, Jun 11, 2002 at 02:26:42PM -0500, Jerry Pendergraft wrote:
> > In file included from /usr/local/include/g++-v3/bits/basic_file.h:250,
> > from /usr/local/include/g++-v3/fstream:48,
>
> Looks like you've installed 3.1 over top of a previous version, which is Bad.
>
> http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_0
>
>
> > /usr/local/include/g++-v3/mips-sgi-irix6.5/bits/basic_file_model.h: In
> > constructor `std::__basic_file<_CharT>::__basic_file(__c_lock*)':
> > /usr/local/include/g++-v3/mips-sgi-irix6.5/bits/basic_file_model.h:39: class `
> > std::__basic_file<_CharT>' does not have any field named `_M_cfile'
> > /usr/local/include/g++-v3/mips-sgi-irix6.5/bits/basic_file_model.h:39: class `
> > std::__basic_file<_CharT>' does not have any field named `_M_cfile_created'
>
> Although that's not the usual error we see in those cases. Can you check
> whether a previous version of GCC might have been installed in /usr/local?
>
>
> Phil
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libstdc++/6998: failure when #include <fstream>
@ 2002-06-11 14:56 Phil Edwards
0 siblings, 0 replies; 8+ messages in thread
From: Phil Edwards @ 2002-06-11 14:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR libstdc++/6998; it has been noted by GNATS.
From: Phil Edwards <phil@jaj.com>
To: Jerry Pendergraft <jerry@endocardial.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/6998: failure when #include <fstream>
Date: Tue, 11 Jun 2002 17:46:36 -0400
On Tue, Jun 11, 2002 at 02:26:42PM -0500, Jerry Pendergraft wrote:
> In file included from /usr/local/include/g++-v3/bits/basic_file.h:250,
> from /usr/local/include/g++-v3/fstream:48,
Looks like you've installed 3.1 over top of a previous version, which is Bad.
http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_0
> /usr/local/include/g++-v3/mips-sgi-irix6.5/bits/basic_file_model.h: In
> constructor `std::__basic_file<_CharT>::__basic_file(__c_lock*)':
> /usr/local/include/g++-v3/mips-sgi-irix6.5/bits/basic_file_model.h:39: class `
> std::__basic_file<_CharT>' does not have any field named `_M_cfile'
> /usr/local/include/g++-v3/mips-sgi-irix6.5/bits/basic_file_model.h:39: class `
> std::__basic_file<_CharT>' does not have any field named `_M_cfile_created'
Although that's not the usual error we see in those cases. Can you check
whether a previous version of GCC might have been installed in /usr/local?
Phil
--
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] 8+ messages in thread
* libstdc++/6998: failure when #include <fstream>
@ 2002-06-11 12:36 Jerry Pendergraft
0 siblings, 0 replies; 8+ messages in thread
From: Jerry Pendergraft @ 2002-06-11 12:36 UTC (permalink / raw)
To: gcc-gnats
>Number: 6998
>Category: libstdc++
>Synopsis: failure when #include <fstream>
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: unassigned
>State: open
>Class: rejects-legal
>Submitter-Id: net
>Arrival-Date: Tue Jun 11 12:36:02 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: jerry pendergraft
>Release: 3.1
>Organization:
endocardial solutions
>Environment:
System: IRIX64 kryten 6.5 04131234 IP28
host: mips-sgi-irix6.5
build: mips-sgi-irix6.5
target: mips-sgi-irix6.5
configured with: /home/builds/gcc-3.1/configure --verbose --enable-shared=no --disable-shared
>Description:
simple program such as:
#include <fstream>
int foo(void)
{
return( 3 * 9 );
}
Compiled by: gcc -c tgcc.C produces
In file included from /usr/local/include/g++-v3/bits/basic_file.h:250,
from /usr/local/include/g++-v3/fstream:48,
from tgcc.C:1:
/usr/local/include/g++-v3/mips-sgi-irix6.5/bits/basic_file_model.h: In
constructor `std::__basic_file<_CharT>::__basic_file(__c_lock*)':
/usr/local/include/g++-v3/mips-sgi-irix6.5/bits/basic_file_model.h:39: class `
std::__basic_file<_CharT>' does not have any field named `_M_cfile'
/usr/local/include/g++-v3/mips-sgi-irix6.5/bits/basic_file_model.h:39: class `
std::__basic_file<_CharT>' does not have any field named `_M_cfile_created'
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-07-03 16:20 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-11 15:36 libstdc++/6998: failure when #include <fstream> Phil Edwards
-- strict thread matches above, loose matches on Subject: below --
2002-07-03 9:20 bkoz
2002-06-11 16:26 Phil Edwards
2002-06-11 16:16 Jerry Pendergraft
2002-06-11 15:36 Jerry Pendergraft
2002-06-11 15:16 Jerry Pendergraft
2002-06-11 14:56 Phil Edwards
2002-06-11 12:36 Jerry Pendergraft
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).