<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>136374</bug_id>
          
          <creation_ts>2006-06-11 03:43 0000</creation_ts>
          <short_desc>sci-misc/boinc needs MAKEOPTS=&quot;-j1&quot; on GCC 4.1.1</short_desc>
          <delta_ts>2006-07-15 16:25:59 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Ebuilds</component>
          <version>unspecified</version>
          <rep_platform>All</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          
          <priority>P2</priority>
          <bug_severity>minor</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>magnus@sonic2000.org</reporter>
          <assigned_to>cryos@gentoo.org</assigned_to>
          <cc>fmccor@gentoo.org</cc>
    
    <cc>sci@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>magnus@sonic2000.org</who>
            <bug_when>2006-06-11 03:43:43 0000</bug_when>
            <thetext>sci-misc/boinc needs to use MAKETOPS=&quot;-j1&quot; to compile correctly.

Refering to the attachment for the error it fails with.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>magnus@sonic2000.org</who>
            <bug_when>2006-06-11 03:44:31 0000</bug_when>
            <thetext>Created an attachment (id=88890)
boinc make error

The error boinc will fail with when compiled with more than one thread</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cryos@gentoo.org</who>
            <bug_when>2006-07-10 06:16:59 0000</bug_when>
            <thetext>Meant to resolve to fixed...</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cryos@gentoo.org</who>
            <bug_when>2006-07-10 06:18:29 0000</bug_when>
            <thetext>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.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>fmccor@gentoo.org</who>
            <bug_when>2006-07-13 08:31:57 0000</bug_when>
            <thetext>I can&apos;t build boinc-5.5.6 on sparc/gcc-3.3.5, but the problem does not seem to be compiler related.  With MAKEOPTS=&apos;-j4&apos; and using distcc, the following sequence appears in the make in the sea directory:
mkdir -p BOINC
cp &lt;file1&gt;.png BOINC
cp &lt;file2&gt;.png BOINC
cp &lt;file3&gt;.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=&apos;-j3&apos;, gcc-3.4.6-r1

However, on my sparc SB1000(1x900, 1x750) system, MAKEOPTS=&apos;-j3&apos;, 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.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cryos@gentoo.org</who>
            <bug_when>2006-07-15 14:54:47 0000</bug_when>
            <thetext>I have seen this once in about 30 compiles of it I have done on my dual core AMD64 system (4400+). I don&apos;t know why it is so rare on my system, possibly my hard drive is pretty fast or I don&apos;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!</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>fmccor@gentoo.org</who>
            <bug_when>2006-07-15 16:19:06 0000</bug_when>
            <thetext>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&apos;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&apos;s what the output from the build loks like.  (For me, the summary would stop with the &apos;-j1&apos; :).)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cryos@gentoo.org</who>
            <bug_when>2006-07-15 16:25:59 0000</bug_when>
            <thetext>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&apos;t have time and am not certain how to fix it just yet.</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>88890</attachid>
            <date>2006-06-11 03:44 0000</date>
            <desc>boinc make error</desc>
            <filename>boinc.error</filename>
            <type>text/plain</type>
            <data encoding="base64">bWtkaXIgLmxpYnMKaTY4Ni1wYy1saW51eC1nbnUtZysrIC1mUElDIC1EUElDIC1JLi4vbGliIC1J
Li4vYXBpIC1JLi4vZGIgLUkuLi9jbGllbnQgLUkuLi90b29scyAtSS4uL3NjaGVkIC1pbmNsdWRl
IC4uL2NvbmZpZy5oIC1PMiAtbWFyY2g9cGVudGl1bTQgLWZvbWl0LWZyYW1lLXBvaW50ZXIgLUkv
dXNyL2luY2x1ZGUgLUkvdXNyL2luY2x1ZGUvb3BlbnNzbCAtbyBib2luY19jbGllbnQgLXN0YXRp
Yy1saWJnY2MgYm9pbmNfY2xpZW50LWFjY3RfbWdyLm8gYm9pbmNfY2xpZW50LWFjY3Rfc2V0dXAu
byBib2luY19jbGllbnQtYXBwLm8gYm9pbmNfY2xpZW50LWFwcF9jb250cm9sLm8gYm9pbmNfY2xp
ZW50LWFwcF9ncmFwaGljcy5vIGJvaW5jX2NsaWVudC1hcHBfc3RhcnQubyBib2luY19jbGllbnQt
Y2hlY2tfc3RhdGUubyBib2luY19jbGllbnQtY2xpZW50X21zZ3MubyBib2luY19jbGllbnQtY2xp
ZW50X3N0YXRlLm8gYm9pbmNfY2xpZW50LWNsaWVudF90eXBlcy5vIGJvaW5jX2NsaWVudC1jc19h
Y2NvdW50Lm8gYm9pbmNfY2xpZW50LWNzX2FwcHMubyBib2luY19jbGllbnQtY3NfYmVuY2htYXJr
Lm8gYm9pbmNfY2xpZW50LWNzX2NtZGxpbmUubyBib2luY19jbGllbnQtY3NfZGF0YS5vIGJvaW5j
X2NsaWVudC1jc19maWxlcy5vIGJvaW5jX2NsaWVudC1jc19wcmVmcy5vIGJvaW5jX2NsaWVudC1j
c19zY2hlZHVsZXIubyBib2luY19jbGllbnQtY3Nfc3RhdGVmaWxlLm8gYm9pbmNfY2xpZW50LWNz
X3RyaWNrbGUubyBib2luY19jbGllbnQtZmlsZV9uYW1lcy5vIGJvaW5jX2NsaWVudC1maWxlX3hm
ZXIubyBib2luY19jbGllbnQtZ3VpX2h0dHAubyBib2luY19jbGllbnQtZ3VpX3JwY19zZXJ2ZXIu
byBib2luY19jbGllbnQtZ3VpX3JwY19zZXJ2ZXJfb3BzLm8gYm9pbmNfY2xpZW50LWhvc3RpbmZv
X25ldHdvcmsubyBib2luY19jbGllbnQtaG9zdGluZm9fdW5peC5vIGJvaW5jX2NsaWVudC1odHRw
X2N1cmwubyBib2luY19jbGllbnQtbG9nX2ZsYWdzLm8gYm9pbmNfY2xpZW50LW1haW4ubyBib2lu
Y19jbGllbnQtbmV0X3N0YXRzLm8gYm9pbmNfY2xpZW50LW5ldF94ZmVyX2N1cmwubyBib2luY19j
bGllbnQtcGVyc19maWxlX3hmZXIubyBib2luY19jbGllbnQtc2NoZWR1bGVyX29wLm8gYm9pbmNf
Y2xpZW50LXNzX2xvZ2ljLm8gYm9pbmNfY2xpZW50LXRpbWVfc3RhdHMubyAgLXB0aHJlYWQgLUwv
dmFyL3RtcC9wb3J0YWdlL2JvaW5jLTUuMi4xNC93b3JrL2JvaW5jLTUuMi4xNC9saWIgLUwvdXNy
L2xpYiAtbGJvaW5jIC1sbnNsIC91c3IvbGliL2xpYmN1cmwuc28gLWxzc2wgLWxjcnlwdG8gLWxk
bCAtbHogLWxjIC1sZ2NjIC1sZ2NjX2VoIC1sc3RkYysrIC1sbSAtbHB0aHJlYWQgbGliYmVuY2ht
YXJrLmEKaTY4Ni1wYy1saW51eC1nbnUtZysrOiBsaWJiZW5jaG1hcmsuYTogTm8gc3VjaCBmaWxl
IG9yIGRpcmVjdG9yeQptYWtlWzJdOiAqKiogW2JvaW5jX2NsaWVudF0gRXJyb3IgMQptYWtlWzJd
OiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Zhci90bXAvcG9ydGFnZS9ib2luYy01LjIuMTQvd29yay9i
b2luYy01LjIuMTQvY2xpZW50JwptYWtlWzFdOiAqKiogW2FsbC1yZWN1cnNpdmVdIEVycm9yIDEK
bWFrZVsxXTogTGVhdmluZyBkaXJlY3RvcnkgYC92YXIvdG1wL3BvcnRhZ2UvYm9pbmMtNS4yLjE0
L3dvcmsvYm9pbmMtNS4yLjE0JwptYWtlOiAqKiogW2FsbF0gRXJyb3IgMgoK
</data>        

          </attachment>
    </bug>

</bugzilla>