Re: libstdc++/6672: <fstream> header produces errors

Re: libstdc++/6672: <fstream> header produces errors

[paolo]

Synopsis: <fstream> header produces errors

State-Changed-From-To: analyzed->closed
State-Changed-By: paolo
State-Changed-When: Fri May 17 07:54:47 2002
State-Changed-Why:
    Now the PR can be safely closed: Gerald Pfeifer added a note to the installation docs (http://gcc.gnu.org/ml/gcc-cvs/2002-05/msg00622.html) and Gaby Dos Reis is working on header file versioning (http://gcc.gnu.org/ml/gcc/2002-05/msg01462.html)

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

Re: libstdc++/6672: <fstream> header produces errors

[paolo]

Synopsis: <fstream> header produces errors

State-Changed-From-To: feedback->analyzed
State-Changed-By: paolo
State-Changed-When: Thu May 16 06:41:15 2002
State-Changed-Why:
    Submitter provided the following feedback. For the time being I will keep the PR open, however, since I agree that at least a note should be added to the installation instructions.
    
    ////////
    
    Hi paolo,
    
    indeed, it is the same problem as reported by  Maurizio Loreti.
    
    And the solution is so easy. The problem is caused by an installation error. 
    
    It is not possible (not any more?) to install different gcc releases into the 
    same directory. I have done this for years without problems. Obviously some 
    header files have been moved without renaming. Old versions of some header 
    files remained at places occurring earlier in the search path, so are 
    preferred to the right ones for a given release. The result is mindbogging. 
    At least I was not the only one to get trapped.
    
    Some analysis and suggestions to the long-standing cause:
    
    Why are big parts of a gcc installation divided by the release numbers, while 
    other important parts are not.  E.g.  $PREFIX/lib/gcc-lib/i686-pc-linux-gnu/ 
    contains a directory for each and every release. Why couldn't the same 
    strategy be adopted for the headers under $PREFIX/include?
    
    Since linking statically is not too frequently done, the same problem with 
    statical libraries is unlikely to become a problem.
    
    It should be avoided to install files under the same place and name under 
    $PREFIX whenever crucial changes have happened, e.g. moving other files. The 
    strategies are already there.
    
    This should be enough to close my bug report. It should be warned against 
    installing different libstdc++ releases under the same $PREFIX. It doesn't 
    work in general with gcc-3.1.
    
    Bernd Strieder

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

Re: libstdc++/6672: <fstream> header produces errors

[paolo]

Synopsis: <fstream> header produces errors

Responsible-Changed-From-To: unassigned->paolo
Responsible-Changed-By: paolo
Responsible-Changed-When: Thu May 16 02:20:42 2002
Responsible-Changed-Why:
    Triaged.
State-Changed-From-To: open->feedback
State-Changed-By: paolo
State-Changed-When: Thu May 16 02:20:42 2002
State-Changed-Why:
    Hi. Your PR bears a *very* close similarity to a problem reported yesterday by Maurizio Loreti, which, in fact, turned out to be due to an improper installation (i.e., target directory *not* cleaned before make install). Could you possibly have a look at the gcc discussion thread beginning here http://gcc.gnu.org/ml/gcc/2002-05/msg01233.html and report on your findings??
    Thanks, Paolo.
    

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

libstdc++/6672: <fstream> header produces errors

[strieder]

>Number:         6672
>Category:       libstdc++
>Synopsis:       <fstream> header produces errors
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 16 01:56:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Bernd Strieder
>Release:        3.1
>Organization:
>Environment:
Linux 2.4 i686
>Description:
The following file compiles with releases gcc-2.95.3 and snapshot gcc-20020513,
but not with gcc-3.1.

#include <fstream>

int main(void)
{
  std::fstream file ("fstreamtest.txt", std::ios::out);

  file << "Test";

}

The bug occurs in file

..gcc/include/g++-v3/bits/basic_file.h

  template<typename _CharT>
    class __basic_file_base: public __c_file_type
    {

__c_file_type is unknown producing a parse error before {

>How-To-Repeat:
Just compile like

g++ -g -O2    fstreamt.cc   -o fstreamt

In file included from /net/bernd/gcc/include/g++-v3/fstream:48,
                 from fstreamt.cc:1:
/net/bernd/gcc/include/g++-v3/bits/basic_file.h:52: parse error before `{'
   token
... subsequent messages omitted

>Fix:
not known

It seems to be recently introduced, since last
snapshot worked.
>Release-Note:
>Audit-Trail:
>Unformatted: