RE: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
-----Original Message----- From: c++-sig-bounces@python.org [mailto:c++-sig-bounces@python.org] On Behalf Of Ralf W. Grosse-Kunstleve Sent: Friday, December 17, 2004 1:24 PM To: Development of Python/C++ integration Subject: RE: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
--- Greg Copeland <GCopeland@efjohnson.com> wrote:
What type of problems did you encounter? Can you describe the types of "workarounds" that you had to implement? Did you encounter any
Ya, that's what I feared. I've heard (unconfirmed) that one vendor's 2.96 may very well be different from another vendor's 2.96 release. Your comment seems to confirm it. Thanks for speaking up! Cheers, Greg Copeland problems
using boost/operators.hpp? Did you get complaints about template default arguments...etc...?
No, this doesn't ring any bells. The problems I had were much more subtle.
I noticed that the gcc 2.96 that comes with Red Hat 7.1 behaves differently than the gcc 2.96 that comes with Red Hat 7.3. Maybe you have yet another variety that calls itself gcc 2.96?
Ralf
__________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 _______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
On 12/17/04 2:40 PM, "Greg Copeland" <GCopeland@efjohnson.com> wrote:
Ya, that's what I feared. I've heard (unconfirmed) that one vendor's 2.96 may very well be different from another vendor's 2.96 release. Your comment seems to confirm it.
[There may be some flaming in this post.] As I understand it, there was _never_ an official GCC 2.96 release. The GNU group uses a system where all version numbers ending in an even digit are exclusively non-final (i.e. alpha/beta) and all version numbers ending in an odd digit are exclusively final. After an odd-number release, the intermediate version in CVS immediately gets renamed to an even number, then further work is done, then a rename to an odd number precedes the next release (and the cycle continues). Certain vendors (e.g. Red Hat) plucked out the GCC code out of CVS at some random point after 2.95 and stuck it on their CDs. This suckered many uninformed users into compiling with beta software. For you, either downgrade to 2.95 or upgrade to any of the 3.x releases. And tell all of your friends to do the same. Sorry, but the definition of "GCC 2.96" is too unstable for any developer to reliably help you. Red Hat, and any others, should apologize to all of their users for being inattentive and hoisting this problem on the users. And apologize to all the developers, like me, who have to "waste" time to educate everyone about the mistake. (Worse, Red Hat picked an intermediate version whose line died without ever having a final release. So users have to pick either an older version without fixed bugs or do a major reorganization for jumping to a new compiler line.)
-----Original Message----- From: c++-sig-bounces@python.org [mailto:c++-sig-bounces@python.org] On Behalf Of Ralf W. Grosse-Kunstleve Sent: Friday, December 17, 2004 1:24 PM To: Development of Python/C++ integration Subject: RE: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
--- Greg Copeland <GCopeland@efjohnson.com> wrote:
What type of problems did you encounter? Can you describe the types of "workarounds" that you had to implement? Did you encounter any problems using boost/operators.hpp? Did you get complaints about template default arguments...etc...?
No, this doesn't ring any bells. The problems I had were much more subtle.
I noticed that the gcc 2.96 that comes with Red Hat 7.1 behaves differently than the gcc 2.96 that comes with Red Hat 7.3. Maybe you have yet another variety that calls itself gcc 2.96?
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
participants (2)
-
Daryle Walker -
Greg Copeland