The ebuild in summary is currently forcing users to use serial make (-j1, no extra job tasks). This seems not to be needed. The ebuild was modified to use -j8 on a truly 8-core SMP system and didn't fail the build, you should either check if it's a particular USE flag to cause the problem, or drop -j1 and leave the user to decide how many jobs to use. I want to remember you that with modern multicore systems, forcing serial make is going to waste a lot of time and resources for users.. Thanks, Diego
Fixed, thanks for checking and reporting this :)
With +gtk +ssl -lua the parallel build fails, yet succeeds with -j1.
Can you get me the build log of the failure? I really cannot reproduce neither at -j8 nor -j10, I'll gladly make sure it's safe if you can show me how it fails.
Created attachment 164073 [details] failure build log And here it is, failing...
USE="ssl -gtk -lua" works USE="gtk ssl -lua" fails on one box and works on another The autoheader step from eautoreconf fails as well.
Nice, I can't see about reproducing this with any setting right now, but I do see in the Makefile the race condition. I tried any -j from 2 to 16 and it builds just fine, both disk-backed and tmpfs. Which make version are you using? And how many jobs?
$ make --version GNU Make 3.81 MAKEOPTS="-j3"
Created attachment 164099 [details, diff] A patch to fix concurrent nmap make. Could you please check whether this patch fixes the build problem for you?
seems to work.
Closing then. Please reopen in case the patch doesn't fix the problem.
