compiling 1_32 in release mode brings the computer to its knees (Modified by Yarden Livnat)
Hi, I'm trying to compile 1_32 on OSX with the latest gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666) however, while the debug version compile in just a few minutes, the 'release' start trashing on : libs/serialization/src/xml_grammar.cpp libs/serialization/src/xml_wgrammar.cpp in effect the compilation takes all the memory and then pages endlessly for hours, bringing the machine down to its knees. my compile command is: sudo bjam -sTOOLS=darwin "-sBUILD=release <threading>multi <define>BOOST_SIGNALS_NAMESPACE=Signals " install where the <define> is for Qt, Anybody has a clue why this is happaning and how to get the compilation to complete (other then copy the two .o from the debug tree into the release tree ? thanks Yarden
On 23 Nov, 2004, at 12:17 AM, Mail Delivery Subsystem wrote:
Hi,
I'm trying to compile 1_32 on OSX with the latest gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666) however, while the debug version compile in just a few minutes, the 'release' start trashing on : libs/serialization/src/xml_grammar.cpp libs/serialization/src/xml_wgrammar.cpp
in effect the compilation takes all the memory and then pages endlessly for hours, bringing the machine down to its knees.
my compile command is:
sudo bjam -sTOOLS=darwin "-sBUILD=release <threading>multi <define>BOOST_SIGNALS_NAMESPACE=Signals " install
where the <define> is for Qt,
Anybody has a clue why this is happaning and how to get the compilation to complete (other then copy the two .o from the debug tree into the release tree ?
The same thing happened to me. Since I'm not using the serialization library, I used the --without-serialization option. Not an ideal solution, especially if you need the serialization lib, but a workaround if you don't. HTH, Glen Simmons
on 11/23/04 9:32 AM, Glen Simmons at gsimmons@macdev.itg.ti.com wrote:
On 23 Nov, 2004, at 12:17 AM, Mail Delivery Subsystem wrote:
Hi,
I'm trying to compile 1_32 on OSX with the latest gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666) however, while the debug version compile in just a few minutes, the 'release' start trashing on : libs/serialization/src/xml_grammar.cpp libs/serialization/src/xml_wgrammar.cpp
in effect the compilation takes all the memory and then pages endlessly for hours, bringing the machine down to its knees.
my compile command is:
sudo bjam -sTOOLS=darwin "-sBUILD=release <threading>multi <define>BOOST_SIGNALS_NAMESPACE=Signals " install
where the <define> is for Qt,
Anybody has a clue why this is happaning and how to get the compilation to complete (other then copy the two .o from the debug tree into the release tree ?
The same thing happened to me. Since I'm not using the serialization library, I used the --without-serialization option. Not an ideal solution, especially if you need the serialization lib, but a workaround if you don't.
HTH, Glen Simmons
On the main list Troy Straszheim post about this problem also. Troy found that it is a compiler bug. If you remove the -O flag from the build options then everything is fine. Troy filed a bug with Apple. Chris
Are these problems maybe fixed with Apple's updated gcc 3.3 build 1671 that got posted to the Apple developer site recently? On Nov 23, 2004, at 10:19 AM, Chris Little wrote:
on 11/23/04 9:32 AM, Glen Simmons at gsimmons@macdev.itg.ti.com wrote:
On 23 Nov, 2004, at 12:17 AM, Mail Delivery Subsystem wrote:
Hi,
I'm trying to compile 1_32 on OSX with the latest gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666) however, while the debug version compile in just a few minutes, the 'release' start trashing on : libs/serialization/src/xml_grammar.cpp libs/serialization/src/xml_wgrammar.cpp
in effect the compilation takes all the memory and then pages endlessly for hours, bringing the machine down to its knees.
my compile command is:
sudo bjam -sTOOLS=darwin "-sBUILD=release <threading>multi <define>BOOST_SIGNALS_NAMESPACE=Signals " install
where the <define> is for Qt,
Anybody has a clue why this is happaning and how to get the compilation to complete (other then copy the two .o from the debug tree into the release tree ?
The same thing happened to me. Since I'm not using the serialization library, I used the --without-serialization option. Not an ideal solution, especially if you need the serialization lib, but a workaround if you don't.
HTH, Glen Simmons
On the main list Troy Straszheim post about this problem also. Troy found that it is a compiler bug. If you remove the -O flag from the build options then everything is fine. Troy filed a bug with Apple.
Chris
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
note the boost test page: http://boost.sourceforge.net/regression-logs/cs-Darwin.html shows build and tests all passing with gcc 3.3 build 1666. I don't know if that helps. Robert Ramey "Thomas Costa" <oohrah@mac.com> wrote in message news:ECC0A694-3D82-11D9-84B9-00039303FB26@mac.com...
Are these problems maybe fixed with Apple's updated gcc 3.3 build 1671 that got posted to the Apple developer site recently?
On Nov 23, 2004, at 10:19 AM, Chris Little wrote:
on 11/23/04 9:32 AM, Glen Simmons at gsimmons@macdev.itg.ti.com wrote:
On 23 Nov, 2004, at 12:17 AM, Mail Delivery Subsystem wrote:
Hi,
I'm trying to compile 1_32 on OSX with the latest gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666) however, while the debug version compile in just a few minutes, the 'release' start trashing on : libs/serialization/src/xml_grammar.cpp libs/serialization/src/xml_wgrammar.cpp
in effect the compilation takes all the memory and then pages endlessly for hours, bringing the machine down to its knees.
my compile command is:
sudo bjam -sTOOLS=darwin "-sBUILD=release <threading>multi <define>BOOST_SIGNALS_NAMESPACE=Signals " install
where the <define> is for Qt,
Anybody has a clue why this is happaning and how to get the compilation to complete (other then copy the two .o from the debug tree into the release tree ?
The same thing happened to me. Since I'm not using the serialization library, I used the --without-serialization option. Not an ideal solution, especially if you need the serialization lib, but a workaround if you don't.
HTH, Glen Simmons
On the main list Troy Straszheim post about this problem also. Troy found that it is a compiler bug. If you remove the -O flag from the build options then everything is fine. Troy filed a bug with Apple.
Chris
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Robert Ramey wrote:
note the boost test page:
http://boost.sourceforge.net/regression-logs/cs-Darwin.html
shows build and tests all passing with gcc 3.3 build 1666.
I don't know if that helps.
It doesn't... That's the usual debug build. This is the reason why I favor doing release regression testing in addition to the debug regression testing. No chance to find workarounds if you don't know of the problems :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
on 11/23/04 2:07 PM, Thomas Costa at oohrah@mac.com wrote:
Are these problems maybe fixed with Apple's updated gcc 3.3 build 1671 that got posted to the Apple developer site recently?
Maybe but it would be a happy accident since the bug has only just been reported. The only way to know would be to download the update and rerun the regression tests in release mode. Chris
These are the only modules in the serialization library ( and probably all of boost that use the spirit library. It would be interesting to know if the spirit library and associated tests build and run correctly. Also, for now the issue is just the compilation of these modules in release mode. This is relatively easy to narrow down if you're so inclined. Start out commenting out the whole module with #if 0 ... #endif It better compile. Move the above statements progressivly compiing the module. Eventually you'll find a small part of the program or perhaps some include module that makes the compiler bomb. I know, its tedious, time consuming, and crude - but effective. I'll double check that my windows version of gcc 3.3 can compile this module in release mode. If your lucky - it won't be able to. Robert Ramey "Mail Delivery Subsystem" <MAILER-DAEMON@mac.com> wrote in message news:BC839C6D-3D17-11D9-AC04-000A9588A24E@mac.com...
Hi,
I'm trying to compile 1_32 on OSX with the latest gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666) however, while the debug version compile in just a few minutes, the 'release' start trashing on : libs/serialization/src/xml_grammar.cpp libs/serialization/src/xml_wgrammar.cpp
in effect the compilation takes all the memory and then pages endlessly for hours, bringing the machine down to its knees.
my compile command is:
sudo bjam -sTOOLS=darwin "-sBUILD=release <threading>multi <define>BOOST_SIGNALS_NAMESPACE=Signals " install
where the <define> is for Qt,
Anybody has a clue why this is happaning and how to get the compilation to complete (other then copy the two .o from the debug tree into the release tree ?
thanks
Yarden
participants (3)
-
Chris Little -
Glen Simmons -
Mail Delivery Subsystem -
Rene Rivera -
Robert Ramey -
Thomas Costa