It's more a request rather than an actual bug, but with a package that takes as long to build as GCC (in particular on multilib systems, way over 1 hour on my Athlon X2 4600+ machine) it'd be a real blessing if the ebuild actually used as many threads as specified in make.conf rather than just one (at least for the most part). Not a big issue on distros where the compiler comes as binary package, but on Gentoo this is a real bummer. Please forward to the GCC developers if you can't do anything about it, rather than just sending it to /dev/null. Reproducible: Always Steps to Reproduce:
could you post some actual information about the problem you think you're experiencing gcc seems to build in parallel just fine on my dual core amd64 and my quad ppc64
Uhm; you've misunderstood the problem; the eclasses disable parallel make.
I usually monitor emerge sessions with gnome-system-monitor and for most packages the graph shows they pretty much saturate my 2 cores once they're in the compile stage (I have MAKEOPTS="-j3" in /etc/make.conf). I monitored the GCC build for a long time today and there was definitely only one _busy_ thread whenever I checked (I noticed that for older GCC builds as well); don't know whether the build isn't parallel at all or the other threads are blocked/sleeping for some reason, but there are definitely a lot of CPU resources wasted here.
i didnt misunderstand anything ... user said he thinks it's running just one job but failed to say how he came to that conclusion the eclass only disables parallel jobs in the cases where parallel jobs are known to fail
Ok, I've kinda traced this down. It seems like toolchain.eclass sets GCC_MAKE_TARGET to ${GCC_MAKE_TARGET}-profiledbootstrap (line 1370) when on x86, amd64, ppc64, gcc > 3.3 (line 1367-1368) and we're not cross-compiling (line 1363), which results in MAKEOPTS being exported as MAKEOPTS="${MAKEOPTS} -j1" (line 1377). I guess there's some override to that since you said that gcc builds with multible jobs on your amd64 and ppc64 what can't be according to what I said above :> Don't shout too loud at me if this is completely wrong, it's 4 AM here *runs*
so what's the question ? profiledbootstrap cannot be run in parallel as the comments in the eclass clearly state
To me it seems like profiledbootstrap is forced on those 4 archs - since I don't even know what profiling exactly does (I guess profiledbootstrap does profiling during bootstrap?) it'd be nice to see some override, like the profile USE flag, so people like us can save a lot of time compiling GCC. BTW, I've commented line 1377 which disabled parallelizing and had no problems compiling GCC 4.2.0, and saved ~15 minutes as opposed to the previous emerge (gcc-4.1.2 52 minutes, gcc-4.2.0 37 minutes).
USE=profile is inappropriate here and considering the benefits for users, i dont think adding a control is of value right now if you read the gcc install documentation, you'll understand: http://gcc.gnu.org/install/build.html (go all the way to the end) i'd rather waste 15 minutes building gcc and gain that and more while building everything else
Well ok, I agree that disabling profiling is a bad idea (guess I have to read up a bit on that :>). I'd like to see something to force it to use parallel make though, like it's done in the openoffice ebuild (if WANT_MP="true"; then...). The GCC docs only mention that collisions _may_ occur, just like openoffice's build system _may_ break when compiling with more than one job.
