emerge process stalled for more than 8 hours, showing no activity, after printing lines Skipping build of: ./build_all <build>no in common properties ...patience... ...patience... ...found 4875 targets... ...updating 1162 targets... setting MAKEOPTS to -j1 solves the problem: Reproducible: Always Steps to Reproduce: 1. MAKEOPTS="--jobs --load-average=3" emerge =dev-libs/boost-1.35.0-r5 2. watch for hang after line "...updating 1162 targets..." and stops Actual Results: emerge hangs forever, not doing anything Expected Results: successful emerge
Created attachment 221901 [details] emerge --info output
Created attachment 221903 [details] unsuccessful emerge log
with my MAKEOPTS bjam-1_35 gets command-line options -j --load-average=3 could this be the reason for the eternal sleep?
Boost ebuild does some magic to figure out number of jobs to run with, as it doesn't use makefiles, so MAKEOPTS isn't picked up. The algo used somewhat evolved in more recent versions, but doesn't seem to be backported.
(In reply to comment #4) > Boost ebuild does some magic to figure out number of jobs to run with, as it > doesn't use makefiles, so MAKEOPTS isn't picked up. The algo used somewhat > evolved in more recent versions, but doesn't seem to be backported. > i did not say that bjam checks for MAKEOPTS in my post no.3 i meant to say that with my value of MAKEOPTS ebuild gives bjam command-line options -j --load-average=3 and my question was whether these options are valid
> i did not say that bjam checks for MAKEOPTS I didn't say that either. > in my post no.3 i meant to say that with my value of MAKEOPTS ebuild gives bjam > command-line options Ebuild isn't giving bjam your MAKEOPTS. It's trying to find out number of jobs by looking at it and then uses it with bjam. Fact that bjam and make use '-j N' to denote number of jobs to run in parallel is a pure coincidence. > -j --load-average=3 > > and my question was whether these options are valid Hack used in 1.35 possibly does not catch that case so no.
This _should_ be fixed now.
