[boost] Re: Build of boost_1_32_0 hangs on MacOS X build

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-19 18:37:18

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_at_[hidden]> wrote in message
news:661E9EC6-39FE-11D9-BE71-003065BC30C0_at_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
>