No SeaMonkey (trunk) builds for linux-x86_64 (latest nightly was on October 5) Assembly errors trying to make compare.o as follows: /builds/slave/comm-cen-trunk-lnx64/build/mozilla/media/webrtc/trunk/third_party/libyuv/source/compare.cc: Assembler messages: /builds/slave/comm-cen-trunk-lnx64/build/mozilla/media/webrtc/trunk/third_party/libyuv/source/compare.cc:220: Error: no such instruction: `pmulld %xmm6,%xmm0' /builds/slave/comm-cen-trunk-lnx64/build/mozilla/media/webrtc/trunk/third_party/libyuv/source/compare.cc:226: Error: no such instruction: `pmulld %xmm5,%xmm3' /builds/slave/comm-cen-trunk-lnx64/build/mozilla/media/webrtc/trunk/third_party/libyuv/source/compare.cc:230: Error: no such instruction: `pmulld %xmm5,%xmm4' /builds/slave/comm-cen-trunk-lnx64/build/mozilla/media/webrtc/trunk/third_party/libyuv/source/compare.cc:235: Error: no such instruction: `pmulld %xmm5,%xmm2' /builds/slave/comm-cen-trunk-lnx64/build/mozilla/media/webrtc/trunk/third_party/libyuv/source/compare.cc:238: Error: no such instruction: `pmulld %xmm5,%xmm1' NEXT ERROR make[7]: *** [source/compare.o] Error 1

P.S. AFAICT from inspection of Tinderbox logs, the bug is solid on all recent L64 hourlies & nightlies.

<jesup> The obvious thing for now is to disable webrtc on comm-central... If they decide to support it, they can try building with it and figure out the right options. The compiler command lines look similar, but CC versions are different, and maybe some other stuff (4.5 vs 4.6) <RattyAway> jesup: ah so we need to build with webrtc as a dependency? <jesup> or if they want to try to support it, disable to for linux64 <RattyAway> jesup: hmm so it works for Firefox linux64? what are we doing differently <jesup> --enable-webrtc is the default. yes, fine in linux64 <RattyAway> Callek is our build config expert perhaps he can figure what we are missing. <jesup> compared compiler command lines, nothing obvious (like missing -mmmx) It's an mmmx compiler config issue in some way <RattyAway> ah perhaps we need to move to CentOS 6? <jesup> It worked fine on linux64 on centos5 though we also updated last week to a new version of webrtc.org code <jesup> RattyAway: could also add YUV_DISABLE_ASM to the libyuv.gyp file though it would be slower

Callek - a comparison of the compiler lines seems similar (to my local linux64 m-i build). different compiler versions (4.5 v 4.6) - shouldn't be it. As a temporary measure, you could --disable-webrtc unless you're using it. Probably not a bad idea until you decide to support at least navigator.mozGetUserMedia() (and UI for user permission to use the camera).

(In reply to Randell Jesup [:jesup] from comment #3) > Callek - a comparison of the compiler lines seems similar (to my local > linux64 m-i build). different compiler versions (4.5 v 4.6) - shouldn't be > it. Both SeaMonkey and m-c MoCo builders use gcc4.5-0-moz2 (from memory). So that shouldn't be it. The only difference is that MoCo builders are currently built inside a mock environment ontop of Cent6, while SeaMonkey machines are on the slightly older build platform. > As a temporary measure, you could --disable-webrtc unless you're using it. > Probably not a bad idea until you decide to support at least > navigator.mozGetUserMedia() (and UI for user permission to use the camera). By doing --disable-webrtc this implies we'll be diverging from some of the newer web-compat features that Gecko [Firefox] now has, correct. If so that is what I'd like to be my last choice.

So to summarize from IRC convo. 1) This is due to us having an older binutils package on the machine 2.17.50.0.6-2 2) "SSE4 support in gas and objdump" was added to binutils in 2.17.50.0.6-4 3) This is enabled by default on x86_64 and based off another check for x86, which explains why linux32 is ok 4) We should be able to turn off the broken behavior [at the cost of some perf] if we define YUV_DISABLE_ASM We'll attempt the define solution, as opposed to disabling webrtc for linux64 in the short term. when we get the mock-based builders up we shouldn't need that.

I have binutils 2.21.1 on this system. Just started a "clobber" own-compile (which may take all night, but that's another question) with a fairly standard mozconfig. We'll see what happens.

In reply to comment #6: :-/ Not enough space on / filesystem (only 624 bytes left).

Cleaned out some space, restarted, libxul link was hell as always but finally ended… and then a little later, "cannot write to <objdir>/mozilla/dist/bin/seamonkey: no space left on device". Well, looks like it would have produced a seamonkey*.tar.bz2 if I'd had just a leeetle more room on the disk. Justin, I hope you can upgrade your binutils some day soon, it seems to be the way.

Verified with a manual build on our linux64 system that this gives us a successful build

Comment on attachment 671235 [details] [diff] [review] [comm-central] add -DYUV_DISABLE_ASM=1 to Linux64 Review of attachment 671235 [details] [diff] [review]: ----------------------------------------------------------------- This had r=Neil[Away] via IRC if I removed the HOST_LDFLAGS so doing that and pushing.

Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0 Firefox/19.0 SeaMonkey/2.16a1 ID:20121016091111 c-c:d5a5ad198a40 m-c:be64e9425b0b Linux64 builds have stopped failing. This one is the second hourly IIUC, and a nightly is currently being built.

Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0 Firefox/19.0 SeaMonkey/2.16a1 ID:20121016141547 c-c:f2e48ec916ba m-c:838eee8853ca FWIW: The nightly works too.

Comment on attachment 671235 [details] [diff] [review] [comm-central] add -DYUV_DISABLE_ASM=1 to Linux64 Review of attachment 671235 [details] [diff] [review]: ----------------------------------------------------------------- Consider adding a comment that these can be dropped when bintools is upgraded

In reply to comment #13: s/bintools/binutils/

Comment on attachment 671235 [details] [diff] [review] [comm-central] add -DYUV_DISABLE_ASM=1 to Linux64 Review of attachment 671235 [details] [diff] [review]: ----------------------------------------------------------------- This had r=Neil[Away] via IRC if I removed the HOST_LDFLAGS so doing that and pushing. (apparantly I never published this comment -- so doing so... needed on aurora too)

> (apparantly I never published this comment -- so doing so... needed on aurora too) Pushed to comm-aurora: http://hg.mozilla.org/releases/comm-aurora/rev/d3b351a705a9

Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0 Firefox/19.0 SeaMonkey/2.16a1 ID:20121103003004 c-c:c42bb5c1cfd0 m-c:2718739a1c83 Nightlies have been built today on Trunk and Aurora for all four of W32, L32, L64 and Mac, and I'm using one of them.

oops: L64 on Aurora was yesterday between 4 and 7 AM, today's nightly hasn't yet started; all others were built today.

I notice that there is no explicit mention in the above comments that the push to Central was comm-central changeset d5a5ad198a40 (from which the build used in comment #11 was built). As jesup mentioned in comment #13, these changesets should be backed out once _all_ SeaMonkey builders for linux-x86_64 are updated to binutils version 2.17.50.0.6-4 or later (cf. Callek's comment #5). This will happen sometime but we have as yet no idea of when. Maybe a followup bug should be opened so we don't forget. L64 builders are green again on Aurora and Central => VERIFIED.

(In reply to Tony Mechelynck [:tonymec] from comment #19) [...] > As jesup mentioned in comment #13, these changesets should be backed out > once _all_ SeaMonkey builders for linux-x86_64 are updated to binutils > version 2.17.50.0.6-4 or later (cf. Callek's comment #5). This will happen > sometime but we have as yet no idea of when. Maybe a followup bug should be > opened so we don't forget. [...] P.S.: I see this has already been done, see bug 795354 comment #1.