sci-misc/boinc needs to use MAKETOPS="-j1" to compile correctly. Refering to the attachment for the error it fails with.
Created attachment 88890 [details] boinc make error The error boinc will fail with when compiled with more than one thread
Meant to resolve to fixed...
Sorry - wrong bug doh... I have just added 5.5.6 to portage and it builds fine here with -j5 on GCC 4.1.1. Please test and let me know if it works OK for you.
I can't build boinc-5.5.6 on sparc/gcc-3.3.5, but the problem does not seem to be compiler related. With MAKEOPTS='-j4' and using distcc, the following sequence appears in the make in the sea directory: mkdir -p BOINC cp <file1>.png BOINC cp <file2>.png BOINC cp <file3>.png BOINC and the performance of this particular system (U2(2x400)) is such that it tries to do the copies before the mkdir actually completes. Similar problem when making sea on a dual processor amd64, MAKEOPTS='-j3', gcc-3.4.6-r1 However, on my sparc SB1000(1x900, 1x750) system, MAKEOPTS='-j3', gcc-3.4.6-r2, the build is successful. So, on multiprocessor systems, the make in the sea directory can fail because the make can try to copy files into a directory before the mkdir succeeds. Notice that the SB1000 is not SMP because the CPUs have different speeds, and it could well be that the mkdirs were assigned to the faster CPU.
I have seen this once in about 30 compiles of it I have done on my dual core AMD64 system (4400+). I don't know why it is so rare on my system, possibly my hard drive is pretty fast or I don't have a clue. I am not sure upon how best to deal with this - ideally patching it but for now I can always force -j1... I hate doing that but if it is causing issues it may be the best solution until the problem is fixed properly. Would this cure the issue for you Ferris? It seems pretty rare on my system but I can see others are experiencing problems with it. A patch would be even better if anyone has one!
Yes, that would solve it for me. But as I said, my problem is just that I need -j1 and it is not compiler related. It's that on a multiprocessor, both a mdir and a cp into that dir start simultaneously, so the cp fails on some systems. At least, that's what the output from the build loks like. (For me, the summary would stop with the '-j1' :).)
I have just added -j1 to the 5.5.6 ebuild. Hopefully this should cure the issue for most people. I would prefer to patch it but I just don't have time and am not certain how to fix it just yet.
