Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Sun, 1 Sep 2002, David O'Brien wrote: On Sun, Sep 01, 2002 at 12:37:14PM -0700, Lamont Granquist wrote: It sounds like gcc-3.1 or gcc-3.2 will be archaic and buggy by the time that 5.2 and 5.3 come out. How would gcc-3.2 get more buggy over time than it is today?? I said it was buggy. Do you mean to imply that gcc-3.2 doesn't have a single bug in it? Admittedly I should have said unmaintained though -- point being that the bugs in it wouldn't be getting fixed by gcc developers who would rather fix them in 3.3... archaic does apply however. Why the fsck can't people come up to speed on an issue before spewing FUD? I fail to see why assuming that a software project the size of the gcc compiler has a few bugs is FUD... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Mon, Sep 02, 2002 at 02:17:25AM -0700, Lamont Granquist wrote: On Sun, 1 Sep 2002, David O'Brien wrote: On Sun, Sep 01, 2002 at 12:37:14PM -0700, Lamont Granquist wrote: It sounds like gcc-3.1 or gcc-3.2 will be archaic and buggy by the time that 5.2 and 5.3 come out. How would gcc-3.2 get more buggy over time than it is today?? I said it was buggy. Do you mean to imply that gcc-3.2 doesn't have a single bug in it? Labling software as buggy is a major put down. If GCC 3.2 is buggy because it has at least one bug; then FreeBSD 4.7 will also be buggy as hell. Admittedly I should have said unmaintained though -- point being that the bugs in it wouldn't be getting fixed by gcc developers who would rather fix them in 3.3... We don't maintain 3.x either -- much to the disappointment of some that based products or major deployments on it. But I do think we support the current release branch much better than the GCC people do. We have a much more liberal MFC policy which lets us continue to fix invasive bugs and add new features. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Mon, 2 Sep 2002, David O'Brien wrote: On Mon, Sep 02, 2002 at 02:17:25AM -0700, Lamont Granquist wrote: On Sun, 1 Sep 2002, David O'Brien wrote: On Sun, Sep 01, 2002 at 12:37:14PM -0700, Lamont Granquist wrote: It sounds like gcc-3.1 or gcc-3.2 will be archaic and buggy by the time that 5.2 and 5.3 come out. How would gcc-3.2 get more buggy over time than it is today?? I said it was buggy. Do you mean to imply that gcc-3.2 doesn't have a single bug in it? Labling software as buggy is a major put down. If GCC 3.2 is buggy because it has at least one bug; then FreeBSD 4.7 will also be buggy as hell. A year from now it probably will be seen as being buggy as hell and i think you're taking the description of buggy far too personally... Software has bugs, over time those bugs surface, some of them are due to design flaws which mean they don't get fixed in older versions and also developers tend to abandon support of older versions. The perception is that the software becomes buggy and it becomes frustrating to work with that software, even if you were perfectly happy with it a year ago. Admittedly I should have said unmaintained though -- point being that the bugs in it wouldn't be getting fixed by gcc developers who would rather fix them in 3.3... We don't maintain 3.x either -- much to the disappointment of some that based products or major deployments on it. But I do think we support the current release branch much better than the GCC people do. We have a much more liberal MFC policy which lets us continue to fix invasive bugs and add new features. Even more reason to try to get as current with gcc as possible with 5.0 -- if they're not liberally MFC'ing to 3.2 then it makes sense to launch 5.0 on a pre-3.3. Otherwise its up to the FreeBSD developers to try to duplicate the gcc developers efforts and patch gcc-3.2 in the 5.0 tree. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Saturday, August 31, 2002, at 06:04 PM, Terry Lambert wrote: David O'Brien wrote: Because rather than leaving it alone for a while, they are already planning a 3.3. 8-). And comments on this list to that effect. I don't follow. The GCC group branches previous to a release and makes an initial + point releases from it. I thought it was the general consensus that the 3.1 version of the compiler was broken, and generated bad code, and that the 3.2 compiler had a lot of these problems corrected, but destroyed binary compatability with 3.1. Yes but if you go through and read gcc.gnu.org you will see that 3.2 can be configured on linux to use the multi-vendor ABI standard. Actually they have been trying to make this work all along and is probably why they break ABI compatibility. 3.1 has issues with template classes that use functions containing static variables [at least a pre-release of it did on Darwin/OS X]. This kind of bug made 3.2 necessary for some people [though I hope every time the fix something that their test-cases increases by one that would be smart anyway]. 3.2 is the more confident ABI and while there are no guarantees that 3.3 will work with 3.2... there seems to be better feelings about it. I guess the fear is that, if they are willing to destroy binary compatability between point releases, with another point release in the wings, it would be risky to pick the point release one behind to standardise upon. There will hopefully always be one behind its called progress. They haven't implemented export yet so they don't have a 100% compliant C++ compiler yet either... no reason to stop. It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. RedHat actually created a release that never occurred [2.96] in the gcc release chain... and if you use it, its actually a pretty nice compiler I know the ABI doesn't work with anything but 2.96 though. How is this different from FreeBSD? (other than they branch much before the .0 release and we don't). FreeBSD has been been branched for 18 months before the 5.0 release; what are you talking about?!? There's not much more much than that, in the entire history of GCC. I thought the comparison was pretty clear myself... FreeBSD current is branched from the same CVS then worked on... the STABLE folks don't usually start whining about all the stuff that's going to be broken for them maybe not until DP2 anyway. :) -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
[EMAIL PROTECTED] wrote: [ ... ] I guess the fear is that, if they are willing to destroy binary compatability between point releases, with another point release in the wings, it would be risky to pick the point release one behind to standardise upon. There will hopefully always be one behind its called progress. They haven't implemented export yet so they don't have a 100% compliant C++ compiler yet either... no reason to stop. Realize that this was a very old discussion which was only recent revived because of David O'Brien's mailer. 8-). The context of this discussion was one of people demanding that David do work to migrate FreeBSD 5.0 to GCC 3.x (2 = x = 3), and the fact that 3.3 will not be officially released until after the scheduled FreeBSD 5.0 release date. It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. RedHat actually created a release that never occurred [2.96] in the gcc release chain... and if you use it, its actually a pretty nice compiler I know the ABI doesn't work with anything but 2.96 though. This is the point I was making in the post previous, to which David's was a reply. The general consensus was that this was a pretty stupid thing for RedHat to do, without the permission of the GCC maintainers. What that means for a FreeBSD 5.0 is a potential incompatability for a point release (something which has never happened in the history of FreeBSD) at some time in the future, when the compiler changes yet again, or a lock-in to an older version of the GCC compiler (something which *has* happened). Both possibilities have their drawbacks. How is this different from FreeBSD? (other than they branch much before the .0 release and we don't). FreeBSD has been been branched for 18 months before the 5.0 release; what are you talking about?!? There's not much more much than that, in the entire history of GCC. I thought the comparison was pretty clear myself... FreeBSD current is branched from the same CVS then worked on... the STABLE folks don't usually start whining about all the stuff that's going to be broken for them maybe not until DP2 anyway. :) It more about what happens overall, when, for example, all the C++ Gnome code has to be recompiled, or the software stops working between point releases, because the GCC folks have broken binary compatability between compiler point releases (again). In any case, the decision of what compiler to import is, as it always has been, up to the guy who doe the work, and so far, that has been David. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Sun, Sep 01, 2002 at 07:41:24AM -0500, [EMAIL PROTECTED] wrote: I thought it was the general consensus that the 3.1 version of the compiler was broken, and generated bad code, and that the 3.2 compiler had a lot of these problems corrected, but destroyed binary compatability with 3.1. Yes but if you go through and read gcc.gnu.org you will see that 3.2 can be configured on linux to use the multi-vendor ABI standard. The multi-vendor ABI standard (agreed upon by all that care about IA-64), was supposed to be properly implemented in 3.1.x. Due to a bug in the implementation 3.1.x wasn't compliant to the new multi-vendor ABI standard. THAT IS THE ONLY REASON 3.2 CAME INTO EXISTENCE. FreeBSD, SuSE, RedHat, Mandrake all have new OS releases coming out this Fall and did not want to go thru an ABI change between 3.1.1 and what was then 3.2 (and is now 3.3). I led the push, strongly supported by some SuSE folks to create a 3.2 which was exactly 3.1.1 + multi-vendor ABI standard compliance fixes. Along the way to 3.2.0 a few other bugs got fixed that would have been in 3.1.2 had the 3.2 we have today not been created. The multi-vendor ABI standard fixes could not go into 3.1.1 or 3.1.2 because the GCC developers have a rule that ABI changes cannot happen in mid-branch. We have the same with our RELENG_X branches. It is *that* simple. Rather than bitch that 3.1.1 sucks; we should thanking the GCC Steering Committee that after much thought they were willing to take the vendors' needs into account. I am not sure FreeBSD would have done the same. Actually they have been trying to make this work all along and is probably why they break ABI compatibility. 3.1 has issues with template classes that use functions containing static variables [at least a pre-release of it did on Darwin/OS X]. Apple highly modifies the GCC sources. So any bugs/problems/issues you find in their compiler you cannot blame on the GCC developers w/o researching the bug/problem/issue. 3.2 necessary for some people [though I hope every time the fix something that their test-cases increases by one that would be smart anyway]. The test suite does. We should be so lucky to have such a test suite. 3.2 is the more confident ABI and while there are no guarantees that 3.3 will work with 3.2... there seems to be better feelings about it. Correct. Not only better feelings but fully intended. But as we saw with 3.1.0, bugs happen. It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. 3.3.0 will be released before FreeBSD 5.1. It is my advice to FreeBSD'ville that we go with a GCC 3.3 snapshot for FBSD 5.0 and a GCC 3.3.0 release for FBSD 5.1. That way we can get the new features of 3.3 into our 5.x branch. AND get bug fixes by importing 3.3.1 and 3.3.2 into later FBSD 5.x releases. RedHat actually created a release that never occurred [2.96] in the gcc release chain... and if you use it, its actually a pretty nice compiler I know the ABI doesn't work with anything but 2.96 though. The ABI was in flux during those times -- the 2.96 ABI is compatabile with nothing else. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
It is *that* simple. yep. Rather than bitch that 3.1.1 sucks; we should thanking the GCC Steering Committee that after much thought they were willing to take the vendors' needs into account. I am not sure FreeBSD would have done the same. I never said it sucked... I think the ABI standardization process is *very* important as it will be an enabling technology... these things don't come without some growing pains. Actually they have been trying to make this work all along and is probably why they break ABI compatibility. 3.1 has issues with template classes that use functions containing static variables [at least a pre-release of it did on Darwin/OS X]. Apple highly modifies the GCC sources. So any bugs/problems/issues you find in their compiler you cannot blame on the GCC developers w/o researching the bug/problem/issue. Wasn't aware to what degree GCC is modified by Apple... I knew they did some things... 3.2 necessary for some people [though I hope every time the fix something that their test-cases increases by one that would be smart anyway]. The test suite does. We should be so lucky to have such a test suite. Indeed! :) 3.2 is the more confident ABI and while there are no guarantees that 3.3 will work with 3.2... there seems to be better feelings about it. Correct. Not only better feelings but fully intended. But as we saw with 3.1.0, bugs happen. Yes... I think you and I are generally on the same page :). It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. 3.3.0 will be released before FreeBSD 5.1. It is my advice to FreeBSD'ville that we go with a GCC 3.3 snapshot for FBSD 5.0 and a GCC 3.3.0 release for FBSD 5.1. That way we can get the new features of 3.3 into our 5.x branch. AND get bug fixes by importing 3.3.1 and 3.3.2 into later FBSD 5.x releases. Yes! yes! YES! :) 100% agree! IMO DP-2 should have gcc-3.3 snap perhaps even FreeBSD 5.0 release [assuming that 5.0 is released on November 20, 2002... I have doubts but I'd rather it be done properly than done quickly... Its one reason I like FreeBSD and the community.] Seems like things are going exactly as they should... going to 3.3 should greatly decrease developer pain overall. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Sun, 1 Sep 2002, David O'Brien wrote: 3.3.0 will be released before FreeBSD 5.1. It is my advice to FreeBSD'ville that we go with a GCC 3.3 snapshot for FBSD 5.0 and a GCC 3.3.0 release for FBSD 5.1. That way we can get the new features of 3.3 into our 5.x branch. AND get bug fixes by importing 3.3.1 and 3.3.2 into later FBSD 5.x releases. 5.0 will be a beta and will not be ready for production use right? If so, it seems perfectly acceptable to use a 3.3 snapshot and risk breaking binary compatibility between 5.0 and 5.1. If it happens, you mention the breakage in UPDATING and people who are using 5.0 should be expected to be paying attention. This way we get to where we want to be, which is 5.2 or 5.3 being a stable operating system with a stable and well-supported compiler. That seems to be the right long-term goal to shoot for. It sounds like gcc-3.1 or gcc-3.2 will be archaic and buggy by the time that 5.2 and 5.3 come out. I'm not sure exactly how FreeBSD would be pulling a redhat by putting in a development snapshot if the 5.0 release is clearly labelled for non-production use only... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Sun, Sep 01, 2002 at 12:37:14PM -0700, Lamont Granquist wrote: It sounds like gcc-3.1 or gcc-3.2 will be archaic and buggy by the time that 5.2 and 5.3 come out. How would gcc-3.2 get more buggy over time than it is today?? archaic does apply however. Why the fsck can't people come up to speed on an issue before spewing FUD? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
David O'Brien wrote: It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. 3.3.0 will be released before FreeBSD 5.1. It is my advice to FreeBSD'ville that we go with a GCC 3.3 snapshot for FBSD 5.0 and a GCC 3.3.0 release for FBSD 5.1. That way we can get the new features of 3.3 into our 5.x branch. AND get bug fixes by importing 3.3.1 and 3.3.2 into later FBSD 5.x releases. This would be my preference, but it would be stupid for me to try to volunteer someone else to do the work. IMO, FreeBSD 5.0 will not be able to gain market acceptance until the 5.1 release, in any case. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
Lamont Granquist wrote: 5.0 will be a beta and will not be ready for production use right? No. But no one will use it anyway, because no one trusts a .0 version of anything. I'm not sure exactly how FreeBSD would be pulling a redhat by putting in a development snapshot if the 5.0 release is clearly labelled for non-production use only... It won't be labelled that way. That's what the -DP versions and the -RC versions are for. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Tue, Aug 27, 2002 at 05:55:18PM -0700, Terry Lambert wrote: In general, though, the answer is that 3.1 sucks and 2.9x does not. 8-). Feh. 3.1's optimizer is less buggy in my experience. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. What in the world are you trying to say?? non-maintenance release??? Why do you think 3.2 is buggy?? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
David O'Brien wrote: On Tue, Aug 27, 2002 at 05:55:18PM -0700, Terry Lambert wrote: In general, though, the answer is that 3.1 sucks and 2.9x does not. 8-). Feh. 3.1's optimizer is less buggy in my experience. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. What in the world are you trying to say?? non-maintenance release??? Why do you think 3.2 is buggy?? Because rather than leaving it alone for a while, they are already planning a 3.3. 8-). And comments on this list to that effect. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Sat, Aug 31, 2002 at 03:06:08PM -0700, Terry Lambert wrote: David O'Brien wrote: On Tue, Aug 27, 2002 at 05:55:18PM -0700, Terry Lambert wrote: In general, though, the answer is that 3.1 sucks and 2.9x does not. 8-). Feh. 3.1's optimizer is less buggy in my experience. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. What in the world are you trying to say?? non-maintenance release??? Why do you think 3.2 is buggy?? Because rather than leaving it alone for a while, they are already planning a 3.3. 8-). And comments on this list to that effect. I don't follow. The GCC group branches previous to a release and makes an initial + point releases from it. How is this different from FreeBSD? (other than they branch much before the .0 release and we don't). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
David O'Brien wrote: Because rather than leaving it alone for a while, they are already planning a 3.3. 8-). And comments on this list to that effect. I don't follow. The GCC group branches previous to a release and makes an initial + point releases from it. I thought it was the general consensus that the 3.1 version of the compiler was broken, and generated bad code, and that the 3.2 compiler had a lot of these problems corrected, but destroyed binary compatability with 3.1. I guess the fear is that, if they are willing to destroy binary compatability between point releases, with another point release in the wings, it would be risky to pick the point release one behind to standardise upon. It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. How is this different from FreeBSD? (other than they branch much before the .0 release and we don't). FreeBSD has been been branched for 18 months before the 5.0 release; what are you talking about?!? There's not much more much than that, in the entire history of GCC. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gcc 3.1 / streambuf.h broken with using namespace std;
Hi! What's going on wrong here? GCC 2.9x can compile this, 3.1 cannot: alex@zerogravity ~ $ cat test.cc using namespace std; #include iostream #include strstream alex@zerogravity ~ $ c++ -pipe -g -fpic -DPIC -Wall -c test.cc In file included from /usr/include/g++/iostream.h:31, from /usr/include/g++/strstream.h:32, from /usr/include/g++/strstream:6, from test.cc:4: /usr/include/g++/streambuf.h:87: syntax error before `*' token /usr/include/g++/streambuf.h:179: syntax error before `*' token /usr/include/g++/streambuf.h:126: warning: `class ios' only defines private constructors and has no friends /usr/include/g++/streambuf.h:180: syntax error before `*' token /usr/include/g++/streambuf.h:180: ISO C++ forbids declaration of `_tie' with no type /usr/include/g++/streambuf.h:180: `val' was not declared in this scope /usr/include/g++/streambuf.h:180: syntax error before `return' In file included from /usr/include/g++/iostream.h:31, from /usr/include/g++/strstream.h:32, from /usr/include/g++/strstream:6, from test.cc:4: /usr/include/g++/streambuf.h:25:1: unterminated #ifndef In file included from /usr/include/g++/strstream.h:32, from /usr/include/g++/strstream:6, from test.cc:4: /usr/include/g++/iostream.h:25:1: unterminated #ifndef In file included from /usr/include/g++/strstream:6, from test.cc:4: /usr/include/g++/strstream.h:27:1: unterminated #ifndef In file included from test.cc:4: alex@zerogravity ~ $ (5 day old -CURRENT) If you remove the using namespace std;, it works, but libh uses a lot of header files that want to use namespace std and are includes before header files that use strstream, and TBH I'm too lazy to add std:: on bazillion places manually. #if 0 Interestingly enough, I've found a VERY similar bug report at Mirosoft's Support base ;-) http://support.microsoft.com/default.aspx?scid=KB;EN-US;q192539; #endif Thanks for any info :) Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Wed, 28 Aug 2002 02:10:06 +0200 Alexander Langer [EMAIL PROTECTED] wrote: alex@zerogravity ~ $ c++ -pipe -g -fpic -DPIC -Wall -c test.cc In file included from /usr/include/g++/iostream.h:31, from /usr/include/g++/strstream.h:32, ^^ There are no such files in gcc 3.1, AFAIK. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Tue, Aug 27, 2002 at 08:24:28PM -0400, Alexander Kabaev wrote: On Wed, 28 Aug 2002 02:10:06 +0200 Alexander Langer [EMAIL PROTECTED] wrote: alex@zerogravity ~ $ c++ -pipe -g -fpic -DPIC -Wall -c test.cc In file included from /usr/include/g++/iostream.h:31, from /usr/include/g++/strstream.h:32, ^^ There are no such files in gcc 3.1, AFAIK. There are, but they are in: /usr/include/g++/backward/iostream.h /usr/include/g++/backward/strstream.h That is from my current system from August 18. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
There are, but they are in: /usr/include/g++/backward/iostream.h /usr/include/g++/backward/strstream.h They are in different place = they are different. Alexander, remove /usr/include/g++ before your next installworld. This is FAQ. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
Alexander Langer wrote: What's going on wrong here? GCC 2.9x can compile this, 3.1 cannot: Delete and reinstall your header files. They must match the compiler you are using, and you must not have stale header files from the previous compiler version. In general, though, the answer is that 3.1 sucks and 2.9x does not. 8-). Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
Thus spake Terry Lambert ([EMAIL PROTECTED]): What's going on wrong here? GCC 2.9x can compile this, 3.1 cannot: Delete and reinstall your header files. They must match the compiler you are using, and you must not have stale header files from the previous compiler version. The -STABLE - -CURRENT upgrade path is broken then. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. I felt like using -CURRENT's 3.1, as it is expected. Well, I'll try to look if a new world fixes the problem, though I bet it won't. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Wed, Aug 28, 2002 at 03:21:39AM +0200, Alexander Langer wrote: I felt like using -CURRENT's 3.1, as it is expected. Well, I'll try to look if a new world fixes the problem, though I bet it won't. rm -rf /usr/include/g++ Now, build your new world. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
Alexander Langer wrote: Thus spake Terry Lambert ([EMAIL PROTECTED]): What's going on wrong here? GCC 2.9x can compile this, 3.1 cannot: Delete and reinstall your header files. They must match the compiler you are using, and you must not have stale header files from the previous compiler version. The -STABLE - -CURRENT upgrade path is broken then. Yes. The same way it leaves the system version of perl installed, instead of deleting it out from under you and forcing you to install the package/port to get perl back. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. I felt like using -CURRENT's 3.1, as it is expected. Well, I'll try to look if a new world fixes the problem, though I bet it won't. If you have anything installed already which you don't rebuild (e.g. C++ libraries), then you will not be able to link the old and new code, since the C++ implementation details have changed sufficiently that object files generated by different versions of the compiler are no longer binary compatible. Going to 3.2 or the 3.3 beta version will at least make an effort toward you not having the problem again, in the future. If you treat -current as a stand-along thing, and not something that's supposed to work all the time, and for which upgrades from source will work without problems, then you won't run into things like this in the future. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
sstream is the correct header. This is not a bug On Tuesday, August 27, 2002, at 08:21 PM, Alexander Langer wrote: Thus spake Terry Lambert ([EMAIL PROTECTED]): What's going on wrong here? GCC 2.9x can compile this, 3.1 cannot: Delete and reinstall your header files. They must match the compiler you are using, and you must not have stale header files from the previous compiler version. The -STABLE - -CURRENT upgrade path is broken then. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. I felt like using -CURRENT's 3.1, as it is expected. Well, I'll try to look if a new world fixes the problem, though I bet it won't. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
