The cpu being built on supports sse4.1, but it is explicitly disabled. Excerpt of the relevent errors: In file included from ../../third_party/libvpx/source/libvpx/vp8/encoder/x86/quantize_sse4.c:12:0: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/smmintrin.h:31:3: error: #error "SSE4.1 instruction set not enabled" # error "SSE4.1 instruction set not enabled" ^ ../../third_party/libvpx/source/libvpx/vp8/encoder/x86/quantize_sse4.c: In function ‘vp8_regular_quantize_b_sse4_1’: ../../third_party/libvpx/source/libvpx/vp8/encoder/x86/quantize_sse4.c:36:5: error: unknown type name ‘__m128i’ __m128i sz0, x0, sz1, x1, y0, y1, x_minus_zbin0, x_minus_zbin1, ^ Reproducible: Always
So don't do that then. I'm not sure what you would expect to happen.
I guess we could start filtering -mno-xx flags in the ebuild.
Created attachment 390168 [details] chromium.log.gz
I expect it to not try to use sse4.1
It always builds with sse4 support, and disables it via a runtime check.
(In reply to Cody Schafer from comment #4) > I expect it to not try to use sse4.1 (In reply to Mike Gilbert from comment #5) > It always builds with sse4 support, and disables it via a runtime check. If that's the case (runtime check), then sure, filter it. To elaborate on my usage: I'm building binpkgs on this box and then using them on a box that doesn't support sse4.1. Building it on the non-sse4.1 box works fine.
(In reply to Cody Schafer from comment #6) > To elaborate on my usage: I'm building binpkgs on this box and then using > them on a box that doesn't support sse4.1. Building it on the non-sse4.1 box > works fine. In that case, filtering might not work if you are using a -march setting that includes sse4.1. This would include -march=native.
To elaborate on that: I am not sure if gcc would generate instructions utilizing sse4 in other areas of the codebase automatically. These auto-generated instructions would not be disabled by the runtime check, which is specific to the assembly routines in libvpx.
(In reply to Mike Gilbert from comment #8) > To elaborate on that: I am not sure if gcc would generate instructions > utilizing sse4 in other areas of the codebase automatically. These > auto-generated instructions would not be disabled by the runtime check, > which is specific to the assembly routines in libvpx. It might, but assuming it obeys my CFLAGs, it won't. All this building is happening in a chroot of gentoo with make.conf's CFLAGs set to the ones autodectected by gcc on the other (non-sse4.1) machine. Which is why the '-mno-sse4.1' flag was included. These aren't just random CFLAGs I came up with :) Also, I've re-examined the non-sse4.1 box, and it appears that chromium hasn't been updated since 36. I'll report back on whether chromium can build at all with '-march=native' on a non-sse4.1 machine.
Created attachment 390176 [details] emerge --info '=www-client/chromium-40.0.2214.10::gentoo'
Created attachment 390178 [details] emerge -pqv '=www-client/chromium-40.0.2214.10::gentoo'
(In reply to Cody Schafer from comment #9) > (In reply to Mike Gilbert from comment #8) > > To elaborate on that: I am not sure if gcc would generate instructions > > utilizing sse4 in other areas of the codebase automatically. These > > auto-generated instructions would not be disabled by the runtime check, > > which is specific to the assembly routines in libvpx. > > It might, but assuming it obeys my CFLAGs, it won't. And now I see what you're saying. I'm using a -march that should disable them (btver1), but it seems the filter of the -mno-sse4 would potentially fit better around the embedded libvpx rather than chromium as a whole.
(In reply to Cody Schafer from comment #12) > And now I see what you're saying. I'm using a -march that should disable > them (btver1), but it seems the filter of the -mno-sse4 would potentially > fit better around the embedded libvpx rather than chromium as a whole. Right. If you were to use a -march setting that enables sse4.1, and we filtered -mno-sse4.1, the resulting binaries may not be usable on a system without sse4.1 support. However, since you are using a -march setting that does NOT enable sse4.1, passing -mno-sse4.1 is basically redundant. Using gcc -v output verbatim is probably not the best idea. The problem is that it negates the -msse4.1 flag that gets passed by the chromium/libvpx build system since your CFLAGS come after it. I'm thinking we just close this as WONTFIX and you should use a saner set of CFLAGS.
(In reply to Mike Gilbert from comment #13) > I'm thinking we just close this as WONTFIX and you should use a saner set of > CFLAGS. FWIW, I agree. I had to deal with people wanting to build Mesa with -mno-sse4.1 under identical circumstances all around.
*** Bug 544702 has been marked as a duplicate of this bug. ***
20 Apr 2015; Mike Gilbert <floppym@gentoo.org> chromium-42.0.2311.90.ebuild, chromium-43.0.2357.18.ebuild, chromium-44.0.2369.0.ebuild: Prevent libvpx build failures. Bug 530248, 544702, 546984.
