boost hangs when building

[misty.de.meo@…]

I can't get the most recent version of boost to build in MacPorts. When attempting to install it, it hangs at the following point while compiling:

darwin.compile.c++ bin.v2/libs/regex/build/darwin-4.2.1/release/address-model-64/architecture-x86/threading-multi/wide_posix_api.o

    "/usr/bin/g++-4.2"  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pedantic -dynamic -no-cpp-precomp -gdwarf-2 -fPIC -arch x86_64  -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -DBOOST_REGEX_DYN_LINK=1 -DNDEBUG  -I"." -I"/opt/local/include" -c -o "bin.v2/libs/regex/build/darwin-4.2.1/release/address-model-64/architecture-x86/threading-multi/wide_posix_api.o" "libs/regex/build/../src/wide_posix_api.cpp"

By "hang", I mean that I've left it at that build stage for hours with no progress.

I do have the previous version of boost installed in MacPorts; the problem is when upgrading. I'm using Mac OS X 10.6.7 with GCC 4.2.1 building for 64-bit.

[misty.de.meo@…]

I left the build running overnight, and here's what I found when I returned in the morning.

First, it hung at a different point - it's not specifically that point where it might hang.

Second, Activity Monitor showed 110 cc1plus processes running as admin - some still using CPU time! - along with probably the same number of g++-4.2 and i686-apple-darwin10-g++-4.2.1 processes. These continued to exist even after I halted the build process using ctrl-c.

[adfernandes@…]

Hmm... I'm guessing that this is a problem with the parallel build system.

Can you try building with just one job, as per  this page?

Specifically, you want sudo port install boost build.jobs=1

Thanks!

[misty.de.meo@…]

That seems to have allowed it to build correctly.

[adfernandes@…]

Hmm... okay. That's good... but I have no idea how to set this ticket. Clearly there is a problem with boost's jam builder... I don't have nearly the time it takes to debug that, so I'm setting to "wontfix" for now.

[misty.de.meo@…]

Fair enough. Is there a way to change the portfile so it builds with a single job by default?

[blb@…]

Why not just set use_parallel_build no in boost's Portfile, then it should at least build for everyone (albeit more slowly)?

[adfernandes@…]

Ha! Good question. Because boost builds very, very slowly without parallel building, and that also gets filed as a bug. See #28224.

[dluke@…]

I would say that it's more important to have it work all of the time than to have it sometimes be fasters (and sometimes not work).

[jmr@…]

Note that this was reported before as #23531.

[adfernandes@…]

Commited in r77331 with a note on how to re-enable it for testing. I like parallel builds because even tiny changes to the Portfile need testing, and without parallelism it can take forever to test things... Thus only Portfile developers should fiddle with parallel building.

[dave@…]

I'd say the slow build time is as much of a bug as the problem noted. I've never seen Boost.Build produce this sort of problem with parallel builds. Are we sure it's at fault?

[adfernandes@…]

Hi, Dave -

No, not 100% sure that parallel builds are at fault. However, I did note that while hacking on the Portfile with parallel builds enabled, I'd get a hang about one build in ten, more-or-less. I've never had a hang without parallel builds. I've had experience debugging parallel/circular dependencies in other projects, though, and this one strongly smells like a parallel-dependency lock.

Regarding the slow build time, that too is expected. I'm sorry if I'm going to sound churlish in what follows, but boost's build system has been a continual source of frustration.

On every phase of the port build, it appears that bjam scans all dependencies for all configurations. Bjam also gets a little confused as to what is configured (debug vs release builds for mpi and python, specifically) and other libraries, so it insists on re-building part of the library on the "install" phase. No idea why. I think that for a default build (static and dynamic libs, standard and multithreaded) it does something like eight to twelve full dependency walks plus various rebuilds. The long build time is therefore not unexpected.

Are you offering to take over ownership of this bug (long build time + possible hang/workaround)?