#28878 closed defect (wontfix)
boost hangs when building
Reported by: | misty.de.meo@… | Owned by: | adfernandes (Andrew Fernandes) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.9.2 |
Keywords: | Cc: | ||
Port: | boost |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
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.
Change History (16)
comment:1 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|---|
Owner: | changed from macports-tickets@… to adfernandes@… |
comment:2 Changed 14 years ago by misty.de.meo@…
comment:3 Changed 14 years ago by adfernandes (Andrew Fernandes)
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!
comment:5 Changed 14 years ago by adfernandes (Andrew Fernandes)
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.
comment:6 Changed 14 years ago by misty.de.meo@…
Fair enough. Is there a way to change the portfile so it builds with a single job by default?
comment:7 Changed 14 years ago by blb@…
Why not just set use_parallel_build no
in boost's Portfile, then it should at least build for everyone (albeit more slowly)?
comment:8 Changed 14 years ago by adfernandes (Andrew Fernandes)
Ha! Good question. Because boost
builds very, very slowly without parallel building, and that also gets filed as a bug. See #28224.
comment:9 Changed 14 years ago by danielluke (Daniel J. Luke)
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).
comment:10 Changed 14 years ago by jmroot (Joshua Root)
Note that this was reported before as #23531.
comment:11 Changed 14 years ago by adfernandes (Andrew Fernandes)
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.
comment:12 Changed 13 years ago by dave@…
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
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?
comment:13 Changed 13 years ago by adfernandes (Andrew Fernandes)
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)?
comment:14 Changed 13 years ago by adfernandes (Andrew Fernandes)
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
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.