When you emerge something wich is a library and needs to be built with libtool utility, you miss half of the complete CPU power and thus it takes more to compile than other C++ program (not library). I noted this when re-emerging for example xine-lib (or kdelibs...) and I saw that my 2 processors (I have an amd64 X-2) are at 50%, while in other emerges, they are at 100% both. I have makeopts="-j3" but it seems that libtool ignores this, or set makeopts="-j1" instead. Reproducible: Always Steps to Reproduce: 1.have multiple CPU (for example a dual core X-2) and a CPU monitor (ie superkaramba wit a theme) 2.emerge some library 3.see that two processors are at 50% instead of near 100% Expected Results: To compile at full speed as all other non-libs programs do.
Such parallelization is entirely the responsibility of the ebuilds src_compile() function. Portage has no control over it.
I reopen this bug as I found a little workarround for this which works for all compilations with autotools (and thus, I changed too the caption of the bug). I tried raising the MAKEOPTS variable to test if it improves the compilations with autotools, and it indeed improves it. So I suggest handling this in portage (for example the autotools eclass, or something else) to raise in two units the number of parallel compilations. For a example, is one has MAKEOPTS="-j3", it can be set temporarily to -j4 or -j5 if autotools is being used to make current package, and revert to normal when finishing. What do you think about this little issue?
I think people should look into using the -l option for MAKEOPTS instead of trying to figure out the right value for -j. Anyway I don't see how portage is involved here.
