-----Original Message----- From: c++-sig-bounces@python.org [mailto:c++-sig-bounces@python.org] On Behalf Of Daryle Walker Sent: Monday, December 20, 2004 4:18 AM To: Python/C++ Integration Development Subject: Re: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks

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

Thanks for the follow up. I'm aware of the Red Hat debacle, however, the "2.96" compiler I'm using, isn't even from a Linux vendor. As such, downgrading or upgrading to the compiler is not an easy solution, so I'm told. I must admit that I'm regurgitating what I've been told and can't vouch for validity of, however, I'm told that the vendor has some custom patches being applied against "their" compiler and will not release them. Worse, I'm also told that key components of their software will not compile with some of gnu's newer compiler releases. End result, we're fairly stuck. I'm still exploring some other options (alternate compiler [non-gnu] provided by vendor), so hopefully this won't prove to be tar pit too. Cheers, Greg Copeland 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

_______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig