Opened 14 years ago

Closed 13 years ago

Last modified 10 years ago

#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@…

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.

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:4 Changed 14 years ago by misty.de.meo@…

That seems to have allowed it to build correctly.

comment:5 Changed 14 years ago by adfernandes (Andrew Fernandes)

Resolution: wontfix
Status: newclosed

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: closedreopened

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: reopenedclosed

comment:15 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:16 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… removed

Cc Me!

Note: See TracTickets for help on using tickets.