[Bug libstdc++/33831] New: [4.3 Regression] Revision 129442 breaks libstc++ API

[Bug libstdc++/33831] New: [4.3 Regression] Revision 129442 breaks libstc++ API

[hjl at lucon dot org]

Revision 129442

http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00547.html

removed many libstdc++ header files from include/backward. That means gcc 4.3
has a different API. It breaks many C++ applications which use the current
libstdc++ API.


-- 
           Summary: [4.3 Regression] Revision 129442 breaks libstc++ API
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl at lucon dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2007-10-20 18:48 -------
Actually there are 15 packages that fail out of 2500 because of this, another
6 from the ext/hash_fun.h move.  I can't tell if in the other 400 packages that
fail with 4.3 for various reasons there are more cases of this.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[hjl at lucon dot org]

------- Comment #2 from hjl at lucon dot org  2007-10-20 19:31 -------
(In reply to comment #1)
> Actually there are 15 packages that fail out of 2500 because of this, another
> 6 from the ext/hash_fun.h move.  I can't tell if in the other 400 packages that
> fail with 4.3 for various reasons there are more cases of this.
> 

I opened PR 33832 for the ext/hash_fun.h move.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[hjl at lucon dot org]

------- Comment #3 from hjl at lucon dot org  2007-10-21 21:41 -------
I believe all those header files should be restored unless we have a very
good reason to break libstdc++ API.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-10-28 00:53 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-10-28 00:53:44
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[bkoz at gcc dot gnu dot org]

-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-10-28 00:53:44         |2007-10-31 21:35:12
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[tbm at cyrius dot com]

------- Comment #5 from tbm at cyrius dot com  2007-12-08 03:10 -------
What's the status of this, Ben?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[bkoz at gcc dot gnu dot org]

------- Comment #6 from bkoz at gcc dot gnu dot org  2007-12-11 22:56 -------

The gcc-4.3 release intentionally changes the libstdc++ API. It is intended
with this release that either:

C++98

or

C++0x

will be used, and that either dialect will work with both TR1 and the various
extensions listed here:

http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/howto.html#2.0

I'm interested in making this change with the least amount of trauma possible.
Some cannot be avoided. The hope is that the new interfaces will be acceptable,
and that the resulting library organization is coherent for the lifespan of
C++0x and future library hacking.

You ask: how can 4.2 and 4.3 libstdc++ APIs be differentiated?

Of course, the usual hackery of GCC predefined macros applies in this
situation:

 __GNUG__ >= 4 &&  __GNUC_MINOR__ >= 3

would work.

However, I think a functional test is a much better way to go.

You'll find a list of autoconf macros to help you through this transition here:

http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/backwards_compatibility.html

In particular:
AC_HEADER_PRE_STDCXX
AC_HEADER_STDCXX_98
AC_HEADER_STDCXX_TR1
AC_HEADER_STDCXX_0X

Should be sufficient to wrap client code. If these (or the other macros on this
page) is insufficient, please let me know. 

To address your comment in #3, I will refer you to:

http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/api.html

>From this, you'll see that the majority of the backwards headers recently
removed were first added for gcc-3.0.0. They have always been marked
deprecated, subject to future removal. Thus, to take a longer-term view of
compiler portability, their presence could never be counted on, even without
the recent removal. To be completely honest, I think adding these headers in
3.0.o0 (when they were not part of gcc-2.72, gcc-2.95, egcs, etc) was a
mistake.

In any case, these headers have been problematic in recent times. Some don't
compile (defalloc.h, perhaps others), some get in the way of other
functionality (complex.h), many are completely unused, and all contribute to
mental anguish on the part of maintainers struggling to keep various C++
dialects, TR1, extensions, and extension modes (debug/parallel) straight and
compiling within the constraints of multiple (approved) mixings.

Hope this clarifies the situation.

best,
benjamin

best,
benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2007-12-11 22:57 -------
Really the change happened too late in the release cycle which is why people
are complaining about this change and it is not that advertised that it would
break many people's code.  In my mind, we should wait for 4.4 for this change.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[bkoz at gcc dot gnu dot org]

------- Comment #8 from bkoz at gcc dot gnu dot org  2007-12-11 23:20 -------

Re: #7.

Sorry about the timing. I agree it is unfortunate. 

I do believe that the correct timing on this is to do both new C++0x interfaces
and the revised backwards includes at the same time. (Certainly, this fits in
with the C++98 effort history and the last backward shuffling in 2001).

All in all, I consider this a distinctly minor disturbance as compared to
compiler changes like -fvisibility, anon namespaces, and 3.4's two-phase lookup
change. 

That said, suggestions for improving the docs to help with this transition
would be appreciated.

-benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[tbm at cyrius dot com]

------- Comment #9 from tbm at cyrius dot com  2007-12-13 03:03 -------
I thought Mark told you two months ago to revert this patch and you didn't
object.  Has anything changed since then?  At this point, I no longer care
whether these headers are removed or not but I'd like to know for sure
so I can start filing bugs.  Given that gcc 4.3 will require almost all
C++ code to be updated and we have several hundred bugs already, filing
those ~70 bugs on packages that use old .h headers isn't that big a deal...


-- 

tbm at cyrius dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[bkoz at gcc dot gnu dot org]

------- Comment #10 from bkoz at gcc dot gnu dot org  2007-12-13 17:13 -------

I am unaware of a reversion request.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[tbm at cyrius dot com]

------- Comment #11 from tbm at cyrius dot com  2007-12-14 02:12 -------
(In reply to comment #10)
> I am unaware of a reversion request.

I cannot find the mail right now via the web interface and I'm travelling and
my gcc mbox files are on a different machine.  Maybe I'm mixing things up then.
But I thought Richi sent a message complaining that SPEC (or some other major
piece of software) got broken by this change and in the discussion it was
agreed to revert the removal.

But, like I said, I cannot find the discussion right now so maybe I dreamt
it.

Richi, do you remember?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[tbm at cyrius dot com]

------- Comment #12 from tbm at cyrius dot com  2007-12-14 05:32 -------
I found it:
http://gcc.gnu.org/ml/gcc/2007-10/msg00389.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[rguenther at suse dot de]

------- Comment #13 from rguenther at suse dot de  2007-12-14 10:16 -------
Subject: Re:  [4.3 Regression] Revision 129442 breaks
 libstc++ API

On Fri, 14 Dec 2007, tbm at cyrius dot com wrote:

> I found it:
> http://gcc.gnu.org/ml/gcc/2007-10/msg00389.html

I don't remember an explicit request for reversing of all those
changes, but there was consensus that breaking the API for old
application is bad.

Now that we have ext/hash_map and ext/hash_set back (yes, SPEC2000
eon still is broken, as it uses the removed iostream.h and other *.h
headers - and it's impossible to fix without touching all of it)
the issue isn't as pressing anymore.  Though still the question
remains if we should break the libstdc++ API at all.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[tbm at cyrius dot com]

------- Comment #14 from tbm at cyrius dot com  2007-12-14 14:15 -------
Well, Mark asked for a good reason for removing the headers, and none was
given,
which would imply the next step would have been to revert their removal.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[mark at codesourcery dot com]

------- Comment #15 from mark at codesourcery dot com  2007-12-17 04:34 -------
Subject: Re:  [4.3 Regression] Revision 129442 breaks
 libstc++ API

rguenther at suse dot de wrote:

> Now that we have ext/hash_map and ext/hash_set back (yes, SPEC2000
> eon still is broken, as it uses the removed iostream.h and other *.h
> headers - and it's impossible to fix without touching all of it)
> the issue isn't as pressing anymore.  Though still the question
> remains if we should break the libstdc++ API at all.

There seemed to be pretty good consensus that we shouldn't.  So far,
other than maintenance pain, I've not seen an argument for removing
things like iostream.h.  And, I think user pain should trump maintenance
pain in this case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[hjl at lucon dot org]

------- Comment #16 from hjl at lucon dot org  2007-12-17 07:01 -------
(In reply to comment #13)
>
> 
> Now that we have ext/hash_map and ext/hash_set back (yes, SPEC2000
> eon still is broken, as it uses the removed iostream.h and other *.h

FWIW, I have 252.eon.gcc43.src.alt.tar.bz2, which works for gcc 4.x. Of course,
it isn't an offical src.alt.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[rguenth at gcc dot gnu dot org]

------- Comment #17 from rguenth at gcc dot gnu dot org  2008-01-16 10:47 -------
So, this is still a P1 regression for 4.3.  Ping!

(I expect Linux distributors will "deal" with this problem, but I also expect
our customers to scream bloody murder at us for this change)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[bkoz at gcc dot gnu dot org]

------- Comment #18 from bkoz at gcc dot gnu dot org  2008-01-16 18:46 -------

The ammount of breakage for this change is IMHO tolerable and will within the
tolerances of other breakages that nobody is talking about reverting, and
furthermore solutions for the API change are well documented. Certainly, the
demonstrated breakage for the pre-iso header removal in fedora builds is about
8 packages, less than most of the individual FE changes in either 4.2 or 4.3. 

I believe there is a bit of a bias here, in that it's OK to make FE changes,
but even well-documented and warned lib changes are not ok? What's up with
that? I assert the right to make API changes, including removal of deprecated
items.

I believe my rationale in #6 has been missed by all. Please directly respond to
this, and tell me why it's ok to remove flags and things like max/min in the
C++FE, and not ok to remove deprecated headers in libstdc++.

I am opposed to wholesale re-instatement of the pre-iso headers, and would like
to close this as WONTFIX. From fedora build failure analysis, only two are
important: iostream.h and fstream.h. If i am to be over-ruled on this issue,
then please only reinstate these two.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[bkoz at gcc dot gnu dot org]

------- Comment #19 from bkoz at gcc dot gnu dot org  2008-01-16 18:58 -------

I'm asking for a libstdc++ maintainer vote on this issue. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[pinskia at gcc dot gnu dot org]

------- Comment #20 from pinskia at gcc dot gnu dot org  2008-01-16 19:06 -------
I still see people use the old deprecated headers all over the place, even in
newer bug reports.  So it is hard to think they will be removed any time soon. 
I am sorry but from a QA point of view, they should be added back because it is
hard to get some folks to update their code (I should know from experience with
the PS3 toolchain upgrade going from 4.0.2 to 4.1.1).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[bkoz at gcc dot gnu dot org]

------- Comment #21 from bkoz at gcc dot gnu dot org  2008-01-16 19:22 -------

> old deprecated headers all over the place

Please give specifics, including what bug reports and what headers. Your
experience is much different from my datapoint, which is Jakub building fedora
with gcc-43. I see 8 fails 5118 packages, 7 iostream.h and 1 fstream.h. 

I still see this change as substantially less impactful than most of the FE
changes since 3.3. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[pinskia at gcc dot gnu dot org]

------- Comment #22 from pinskia at gcc dot gnu dot org  2008-01-16 19:27 -------
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34778 is one example, this example
just came into today.  There are many more.  A lot of the windows/xbox360 based
games use the deprecated headers also.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[rguenther at suse dot de]

------- Comment #23 from rguenther at suse dot de  2008-01-16 19:40 -------
Subject: Re:  [4.3 Regression] Revision 129442 breaks
 libstc++ API

On Wed, 16 Jan 2008, bkoz at gcc dot gnu dot org wrote:

> ------- Comment #21 from bkoz at gcc dot gnu dot org  2008-01-16 19:22 -------
> 
> > old deprecated headers all over the place
> 
> Please give specifics, including what bug reports and what headers. Your
> experience is much different from my datapoint, which is Jakub building fedora
> with gcc-43. I see 8 fails 5118 packages, 7 iostream.h and 1 fstream.h. 
> 
> I still see this change as substantially less impactful than most of the FE
> changes since 3.3. 

I agree with that.

I am inclined to just accept whatever the libstdc++ maintainers decide on.
So I would suggest to gather a vote there and close this bug as WONTFIX
if the consensus is to keep the current state.

Thanks,
Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[fang at csl dot cornell dot edu]

------- Comment #24 from fang at csl dot cornell dot edu  2008-01-16 22:21 -------
A compromise might be to provide the headers only if specifically requested,
say, by -fbackward-headers (something more specific than -fpermissive).  So by
default, the compiler/preprocessor will now error out, but those desparate for
a quick workaround can add a flag.  I've seen too many projects/developers
disregard the current backwards header warning (laziness? indifference?). 
Upgrading to an error with a workaround is yet another step on the road to
deprecation.  Yes, you'll still get some screams in the middle of the night
(and bug reports), but at least this provides an easy way out.  

(IANAM, but I'd be in favor of killing the pre-ISO headers over keeping them.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[mark at codesourcery dot com]

------- Comment #25 from mark at codesourcery dot com  2008-01-16 22:27 -------
Subject: Re:  [4.3 Regression] Revision 129442 breaks
 libstc++ API

bkoz at gcc dot gnu dot org wrote:

> I believe there is a bit of a bias here, in that it's OK to make FE changes,
> but even well-documented and warned lib changes are not ok? What's up with
> that? I assert the right to make API changes, including removal of deprecated
> items.

No, as I've said before, I think the C++ maintainers -- mostly me! --
were just plain wrong about some of the changes made.

I think that some of the changes that were made were necessary because
they were the only way to increase our ability to accept correct,
conformance code.  In other words, sometimes we had to choose between
backwards-compatibility and correctness.  In those cases, I think we
were right to choose correctness.

In other cases, we could have kept compatibility, but didn't.  In some
of those cases, I think we -- and again, mostly, be "we" I mean "I"! --
didn't try hard enough to keep backwards compatibility.  We've being
punished for that.  (Note that there's a recent discussion about making
things that are errors by default into warnings by default -- thereby
making the compiler more lenient.)

My -- possibly incorrect -- understanding is that in this case the
problem with the old headers is not that it prevents implementation of
an ISO-conformant C++ library,  but just that they're a pain to keep
around.  My feeling is that we should be very reluctant to break
backwards compatibility "for maintenance reasons".

Fedora (or any other GNU/Linux distribution) packages are not a good
measure of the problem.  They're good sample of free and/or open-source
codebases compiled with G++, but they're a poor sample of all code
compiled with G++.  We see a lot of dusty-deck C++ code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[pinskia at gcc dot gnu dot org]

------- Comment #26 from pinskia at gcc dot gnu dot org  2008-01-16 22:34 -------
I should make a mention, that I added for the GCC 4.1.1 based PS3 toolchain an
option to give source compatibility for GCC 4.0.2, if anyone wants the patch, I
can provide it.  It was mostly C++ front-end changes too; it adds a couple of
new options which could change the behavior of what is valid C++.  I will most
likely do the same when we upgrade to GCC 4.3.0 (if we do) so the PS3
developers don't have to change their code when updating the compiler.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[bkoz at gcc dot gnu dot org]

------- Comment #27 from bkoz at gcc dot gnu dot org  2008-01-16 23:41 -------


> My -- possibly incorrect -- understanding is that in this case the
> problem with the old headers is not that it prevents implementation of
> an ISO-conformant C++ library,  but just that they're a pain to keep
> around.

You are incorrect. Please do me a favor and read #6, including links, before
replying to this thread.

"In any case, these headers have been problematic in recent times. Some don't
compile (defalloc.h, perhaps others), some get in the way of other
functionality (complex.h), many are completely unused, and all contribute to
mental anguish on the part of maintainers struggling to keep various C++
dialects, TR1, extensions, and extension modes (debug/parallel) straight and
compiling within the constraints of multiple (approved) mixings."

This is far more justification than you gave for the removal of min/max....
although I do appreciate your commentary about backwards compat. You may be
interested to know that I actually did extensive analysis of the libstdc++ api
compat: see the API docs on the libstdc++ page. (Again, referenced in #6).

It's been frustrating to argue this point, as there are 3 separate header
changes for 4.3: removing pre-iso, new deprecations, and header streamlining.
Nobody seems to pay attention as I disambiguate this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[tbm at cyrius dot com]

------- Comment #28 from tbm at cyrius dot com  2008-01-17 06:26 -------
(In reply to comment #21)
> Please give specifics, including what bug reports and what headers. Your
> experience is much different from my datapoint, which is Jakub building fedora
> with gcc-43. I see 8 fails 5118 packages, 7 iostream.h and 1 fstream.h. 

When I last compiled the Debian archive, I saw about 65 failures out of
7000 packages.  Here are the headers that were missing (this adds up to more
than 65 because some files include more than one header that's missing):

    137 error: iostream.h: No such file or directory
     99 error: fstream.h: No such file or directory
      7 error: new.h: No such file or directory
      5 error: stream.h: No such file or directory
      4 error: vector.h: No such file or directory
      3 error: iomanip.h: No such file or directory
      2 error: algo.h: No such file or directory
      2 error: list.h: No such file or directory
      2 error: version.h: No such file or directory
      1 error: alloc.h: No such file or directory
      1 error: ext/hash_fun.h: No such file or directory
      1 error: map.h: No such file or directory
      1 error: pair.h: No such file or directory
      1 error: set.h: No such file or directory
      1 error: streambuf.h: No such file or directory

> I still see this change as substantially less impactful than most of the
> FE changes since 3.3. 

I agree with that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[bkoz at gcc dot gnu dot org]

------- Comment #29 from bkoz at gcc dot gnu dot org  2008-01-18 08:35 -------

I asked for two votes:

1) keep removal of pre-iso includes, (ie current sources). Majority approves.

2) reinstate just iostream.h and fstream.h. Majority declines.

Therefore, I am closing this as WONTFIX as per Richard's suggestion.

-benjamin


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[rguenther at suse dot de]

------- Comment #30 from rguenther at suse dot de  2008-01-18 09:14 -------
Subject: Re:  [4.3 Regression] Revision 129442 breaks
 libstc++ API

On Fri, 18 Jan 2008, bkoz at gcc dot gnu dot org wrote:

> ------- Comment #29 from bkoz at gcc dot gnu dot org  2008-01-18 08:35 -------
> 
> I asked for two votes:
> 
> 1) keep removal of pre-iso includes, (ie current sources). Majority approves.
> 
> 2) reinstate just iostream.h and fstream.h. Majority declines.
> 
> Therefore, I am closing this as WONTFIX as per Richard's suggestion.

Thanks.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831