public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* 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-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 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-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> Jerry Pendergraft
  -- 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 Phil Edwards
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).