I figured that using a non-classical MAKEOPTS="--jobs=X" prevents boost to build. This is due to its rather simple "parsing" by a sed script, which in my case passes garbage to bjam. For those who wonder where the "notice: could not find main target" message comes from, now you know ;)
Thanks for the report, assigning to maintainer
A fix was included in the latest batch of boost ebuilds committed last week (as noted in ChangeLog), though I can't resist pointing out that the sed could still be improved by swapping the two statements so that MAKEOPTS='--junk --jobs=X --otherjunk' would turn into -jX (without --junk and --otherjunk)
confirmed with dev-libs/boost-1.35.0-r2. MAKEOPTS='-j -l 8' results in the same error
Well, sorry Luke. Unless we get PORTAGE_PARALLELITY_LEVEL that would contain a single positive integer that could be used in make, bjam, scons, wthv, developers can't endlessly try and parse every possible make cmdline options combinations. Maintainer here is kind enough not to force -j1 on everyone.
As a variant of this problem, allowing -lN from $MAKEOPTS to reach bjam tends to cause the build to fail. GNU make treats -lN as a load average limit, so it is sometimes used to mitigate the effects of a high -jN, which is sometimes used in large distcc farms. Unfortunately, bjam treats -l as a time limit on how long subprocesses can run before they are killed. Thus, if $MAKEOPTS contains -l 7, then any bjam child that takes longer than 7 seconds to run will be killed and the build considered a failure.
dev-libs/boost-1.39.0 fails to build with MAKEOPTS="-j3" in /etc/make.conf but compiles with MAKEOPTS="-j1" error message below (translated by me from german error messages, did not want to rerun the lengthy compilation just to be sure abut the verbatim wording) -- [...] gcc.compile.c++ bin.v2/libs/math/build/gcc-4.4/gentoorelease/threading-multi/nextafterl.o gcc.compile.c++ bin.v2/libs/math/build/gcc-4.4/gentoorelease/threading-multi/tgammal.o x86_64-pc-linux-gnu-g++: libs/math/build/../src/tr1/tgammal.cpp: file or directory not found x86_64-pc-linux-gnu-g++: no input "x86_64-pc-linux-gnu-g++" -ftemplate-depth-128 -march=native -O2 -Wno-strict-aliasing -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_MATH_TR1_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/math/build/gcc-4.4/gentoorelease/threading-multi/tgammal.o" "libs/math/build/../src/tr1/tgammal.cpp" ...failed gcc.compile.c++ bin.v2/libs/math/build/gcc-4.4/gentoorelease/threading-multi/tgammal.o... gcc.compile.c++ bin.v2/libs/math/build/gcc-4.4/gentoorelease/threading-multi/roundl.o gcc.compile.c++ bin.v2/libs/math/build/gcc-4.4/gentoorelease/threading-multi/nexttowardl.o ...failed updating 1 target... ...updated 847 targets... * ERROR: dev-libs/boost-1.39.0 failed: * building boost failed [...]
I think the main problem is that the two commands in the sed script out of order. If the order is reversed, as follows, it should resolve the problem: sed -r -e 's/--jobs=?/-j/; s/.*(-j ?[0-9]+).*/\1/'
*** Bug 295623 has been marked as a duplicate of this bug. ***
*** Bug 295931 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > I think the main problem is that the two commands in the sed script out of > order. If the order is reversed, as follows, it should resolve the problem: > > sed -r -e 's/--jobs=?/-j/; s/.*(-j ?[0-9]+).*/\1/' > Could you come up with a solution for the problem in bug 295931? It's MAKEOPTS="<junk> -j <junk>". We need to remove this (and build non-parallel). The reasoning is that the user expects the system to not exceed a given load and we can't manage this with something else than -j1.
How about this: jobs=$( echo " $MAKEOPTS " | \ sed -e 's/ --jobs[= ]/ -j /g' \ -e 's/ -j \([1-9][0-9]*\)/ -j\1/g' \ -e 's/ -j\>/ -j1/g' | \ ( while read -d ' ' j ; do if [[ "${j#-j}" = "$j" ]]; then continue; fi; jobs="${j#-j}"; done; echo $jobs ) ) How it works: first, convert the long form into the short form. Next, we look for -j N for an integer N, and convert it to -jN. In the case referenced, -j is followed by a non-integer, so it is left alone. Finally, per request in comment #10, a bare -j is converted to -j1. The sed expression is responsible for normalizing the various jobs forms, then the bash loop reads through them to find the last occurrence of a -jN. Anything that does not start with -j is ignored, to avoid passing through options like -l, which confuse bjam into doing the wrong thing. The last match wins within the loop, which is then echoed and stored into $jobs in the main shell. The inner parentheses are necessary so that the "echo $jobs" and "while read" are in the same subshell.
This should work okay with dev-libs/boost-1.41.0-r1.
Closing as FIXED. By all means reopen if this is still problematic.