Build of boost_1_32_0 hangs on MacOS X build
Could other MacOS X developers confirm that the boost build 1.32 candidate fails to build on MacOS 10.3.6 with gcc 3.3? The problem I'm seeing is that while compiling "xml_grammar.cpp", cc1plus slows to a crawl while its virtual memory allocation rises to 1.8GB until my system becomes so unresponsive I have to kill it. Jam then proceeds until the release build of "xml_grammar.cpp", with the same results (cc1plus hanging). Killing that process leads to the same problems in the debug compile of "xml_wgrammar.cpp", as well as the release compile of "xml_wgrammar.cpp". I have observed this problem both with a dual-processor G5 and a single-processor G4. Everything else in the build seems to be proceed OK after I kill the cc1plus processes that hang on "xml_grammar.cpp". The command line I'm using to build is: bjam -sTOOLS=darwin -sBUILD="debug release <runtime-link>static/dynamic" Please let me know if anyone is having better luck with this. Best regards, Steve Hartwell p.s. There is an additional difficulty with the build of boost 'serialization' where some directory names end with ".a" and ".dylib". Although these are legal directory names, this confuses the heck out of the Xcode IDE, and makes it impossible to include the contents of these named directories into an Xcode project. It would be nice if the names of these directories could be changed to end with "_a" and "_dylib" instead, or something similar. p.p.s. boring (but precise) stuff about the cc1plus hang follows: When cc1plus hangs, ps shows the following arguments: /usr/libexec/gcc/darwin/ppc/3.3/cc1plus -quiet -Ibin/boost/libs/serialization/build -I/usr/include -I/Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0 -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__APPLE_CC__=1666 -D__DYNAMIC__ -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 /Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0/libs/serialization/build/../src/ xml_wgrammar.cpp -D__GNUG__=3 -fPIC -quiet -dumpbase xml_wgrammar.cpp -auxbase-strip bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/runtime-link-static/xml_wgrammar o -O3 -Wno-long-double -Wno-inline -Wall -ftemplate-depth-256 -finline-functions -fcoalesce-templates -D__private_extern__=extern -o Since this is all 'ps' is willing to output for this process, here is the parent process, whose arg list seems more complete: c++ -c -ftemplate-depth-256 -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 -Wno-long-double -no-cpp-precomp -O3 -finline-functions -Wno-inline -Wall -fcoalesce-templates -Ibin/boost/libs/serialization/build -I/usr/include -I/Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0 -o bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/runtime-link-static/xml_wgrammar.o /Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0/libs/serialization/build/../src/ xml_wgrammar.cpp
Hi, I have the same on a dual G4/2Gb. Traced the cause? Kon On Nov 18, 2004, at 11:41 PM, Steve Hartwell wrote:
Could other MacOS X developers confirm that the boost build 1.32 candidate fails to build on MacOS 10.3.6 with gcc 3.3? <snip> c++ -c -ftemplate-depth-256 -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 -Wno-long-double -no-cpp-precomp -O3 -finline-functions -Wno-inline -Wall -fcoalesce-templates -Ibin/boost/libs/serialization/build -I/usr/include -I/Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0 -o bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/runtime-link-static/xml_wgrammar.o /Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0/libs/serialization/build/../src/ xml_wgrammar.cpp
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I have a crude workaround: don't build the "release" version. xml_grammar builds fine in debug mode, but the compiler crashes and burns as described if it is told to optimize. (Does an Apple compiler group exist, and if so, are they listening?). -t Kon Lovett writes:
Hi,
I have the same on a dual G4/2Gb. Traced the cause?
Kon
On Nov 18, 2004, at 11:41 PM, Steve Hartwell wrote:
Could other MacOS X developers confirm that the boost build 1.32 candidate fails to build on MacOS 10.3.6 with gcc 3.3? <snip> c++ -c -ftemplate-depth-256 -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 -Wno-long-double -no-cpp-precomp -O3 -finline-functions -Wno-inline -Wall -fcoalesce-templates -Ibin/boost/libs/serialization/build -I/usr/include -I/Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0 -o bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/runtime-link-static/xml_wgrammar.o /Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0/libs/serialization/build/../src/ xml_wgrammar.cpp
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
At 11:19 PM 11/19/2004, troy d. straszheim wrote:
(Does an Apple compiler group exist, and if so, are they listening?).
Apple does have a compiler group, and at least one of its members posts here occasionally. But if they are like a lot of other compiler support groups, the real way to get them to fix problems is to file a bug report. That is much more likely to produce action than hoping one of them does something about a boost posting. --Beman
On Sat, 20 Nov 2004 15:37:51 -0500, Beman Dawes <bdawes@acm.org> wrote:
At 11:19 PM 11/19/2004, troy d. straszheim wrote:
(Does an Apple compiler group exist, and if so, are they listening?).
Apple does have a compiler group, and at least one of its members posts here occasionally.
But if they are like a lot of other compiler support groups, the real way to get them to fix problems is to file a bug report. That is much more likely to produce action than hoping one of them does something about a boost posting.
Correct on all fronts. A self-contained test case would be very useful. Signed, Matt Austern, member of Apple's compiler group
On Sat, 20 Nov 2004 19:57:17 -0500, troy d. straszheim <troy@resophonic.com> wrote:
to get them to fix problems is to file a bug report. That is much more
Already filed.
Do you happen to have the radar number? I'd like to take a look myself to make sure it doesn't get lost. --Matt
I believe this is one of the configurations tested on a regular basis. See http://www.meta-comm.com/engineering/boost-regression/developer/serializatio n.html . It shows darwin passing all but one test. You might look here and try to get info from the tester as to what might be different. Robert Ramey "Steve Hartwell" <shspamsink@comcast.net> wrote in message news:661E9EC6-39FE-11D9-BE71-003065BC30C0@comcast.net...
Could other MacOS X developers confirm that the boost build 1.32 candidate fails to build on MacOS 10.3.6 with gcc 3.3?
The problem I'm seeing is that while compiling "xml_grammar.cpp", cc1plus slows to a crawl while its virtual memory allocation rises to 1.8GB until my system becomes so unresponsive I have to kill it. Jam then proceeds until the release build of "xml_grammar.cpp", with the same results (cc1plus hanging). Killing that process leads to the same problems in the debug compile of "xml_wgrammar.cpp", as well as the release compile of "xml_wgrammar.cpp".
I have observed this problem both with a dual-processor G5 and a single-processor G4. Everything else in the build seems to be proceed OK after I kill the cc1plus processes that hang on "xml_grammar.cpp".
The command line I'm using to build is: bjam -sTOOLS=darwin -sBUILD="debug release <runtime-link>static/dynamic"
Please let me know if anyone is having better luck with this.
Best regards,
Steve Hartwell
p.s. There is an additional difficulty with the build of boost 'serialization' where some directory names end with ".a" and ".dylib". Although these are legal directory names, this confuses the heck out of the Xcode IDE, and makes it impossible to include the contents of these named directories into an Xcode project. It would be nice if the names of these directories could be changed to end with "_a" and "_dylib" instead, or something similar.
p.p.s. boring (but precise) stuff about the cc1plus hang follows:
When cc1plus hangs, ps shows the following arguments:
/usr/libexec/gcc/darwin/ppc/3.3/cc1plus -quiet -Ibin/boost/libs/serialization/build -I/usr/include -I/Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0 -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__APPLE_CC__=1666 -D__DYNAMIC__ -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 /Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0/libs/serialization/build/../src/ xml_wgrammar.cpp -D__GNUG__=3 -fPIC -quiet -dumpbase xml_wgrammar.cpp -auxbase-strip bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/runtime-link-static/xml_wgrammar o -O3 -Wno-long-double -Wno-inline -Wall -ftemplate-depth-256 -finline-functions -fcoalesce-templates -D__private_extern__=extern -o
Since this is all 'ps' is willing to output for this process, here is the parent process, whose arg list seems more complete:
c++ -c -ftemplate-depth-256 -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 -Wno-long-double -no-cpp-precomp -O3 -finline-functions -Wno-inline -Wall -fcoalesce-templates -Ibin/boost/libs/serialization/build -I/usr/include -I/Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0 -o bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/runtime-link-static/xml_wgrammar.o /Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0/libs/serialization/build/../src/ xml_wgrammar.cpp
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Assuming the debug version builds and passes all tests. In the serialization Jamfile, set the release mode optimization switches to be the same as the debug ones. Try to build. If it passes add optimization switches one at a time until we find the "magic one" which is creating the problem. Then we either alter the Jamfile or amend xml_grammar.cpp with the appropriate #pragma to suppress that optimization. I know its tedious but its the only way I know. Keep me posted Robert Ramey "Steve Hartwell" <shspamsink@comcast.net> wrote in message news:661E9EC6-39FE-11D9-BE71-003065BC30C0@comcast.net...
Could other MacOS X developers confirm that the boost build 1.32 candidate fails to build on MacOS 10.3.6 with gcc 3.3?
The problem I'm seeing is that while compiling "xml_grammar.cpp", cc1plus slows to a crawl while its virtual memory allocation rises to 1.8GB until my system becomes so unresponsive I have to kill it. Jam then proceeds until the release build of "xml_grammar.cpp", with the same results (cc1plus hanging). Killing that process leads to the same problems in the debug compile of "xml_wgrammar.cpp", as well as the release compile of "xml_wgrammar.cpp".
I have observed this problem both with a dual-processor G5 and a single-processor G4. Everything else in the build seems to be proceed OK after I kill the cc1plus processes that hang on "xml_grammar.cpp".
The command line I'm using to build is: bjam -sTOOLS=darwin -sBUILD="debug release <runtime-link>static/dynamic"
Please let me know if anyone is having better luck with this.
Best regards,
Steve Hartwell
p.s. There is an additional difficulty with the build of boost 'serialization' where some directory names end with ".a" and ".dylib". Although these are legal directory names, this confuses the heck out of the Xcode IDE, and makes it impossible to include the contents of these named directories into an Xcode project. It would be nice if the names of these directories could be changed to end with "_a" and "_dylib" instead, or something similar.
p.p.s. boring (but precise) stuff about the cc1plus hang follows:
When cc1plus hangs, ps shows the following arguments:
/usr/libexec/gcc/darwin/ppc/3.3/cc1plus -quiet -Ibin/boost/libs/serialization/build -I/usr/include -I/Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0 -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__APPLE_CC__=1666 -D__DYNAMIC__ -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 /Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0/libs/serialization/build/../src/ xml_wgrammar.cpp -D__GNUG__=3 -fPIC -quiet -dumpbase xml_wgrammar.cpp -auxbase-strip bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/runtime-link-static/xml_wgrammar o -O3 -Wno-long-double -Wno-inline -Wall -ftemplate-depth-256 -finline-functions -fcoalesce-templates -D__private_extern__=extern -o
Since this is all 'ps' is willing to output for this process, here is the parent process, whose arg list seems more complete:
c++ -c -ftemplate-depth-256 -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 -Wno-long-double -no-cpp-precomp -O3 -finline-functions -Wno-inline -Wall -fcoalesce-templates -Ibin/boost/libs/serialization/build -I/usr/include -I/Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0 -o bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/runtime-link-static/xml_wgrammar.o /Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0/libs/serialization/build/../src/ xml_wgrammar.cpp
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (6)
-
Beman Dawes -
Kon Lovett -
Matt Austern -
Robert Ramey -
Steve Hartwell -
troy d. straszheim