On many 32-bits systems, installing Chromium fails since sse/mmx compile flags is (as far as we can tell) not well handled in the ebuild. At least this problem is present in chromium-72.0.3626.28-r1 and chromium-71.0.3578.98. The emerge chromium would fail on audio_bus.cc with: ../../media/base/audio_bus.cc -o obj/media/shared_memory_support/audio_bus.o ninja: build stopped: subcommand failed. * ERROR: www-client/chromium-71.0.3578.98::gentoo failed (compile phase): * ninja -v -j4 -l0 -C out/Release v8_context_snapshot_generator failed * * Call stack: * ebuild.sh, line 124: Called src_compile * environment, line 4212: Called eninja '-C' 'out/Release' 'v8_context_snapshot_generator' We have tracked down the problem to the ebuild's handling of sse/mmx. On this particular install, we specifically need to compile for i686 CPUs with mmx, sse and sse2, which is probably the most common 32-bit architecture still in use today. Hence, our generic CFLAGS in /etc/portage/make.conf are "-O2 -march=i686 -mmmx -msse -msse2 -pipe". This works fine for all packages so far except Chromium. This is what we believe happen: audio_bus.cc needs sse. Hence, the above compile flags should be OK for Chromium. However, using the most recent ebuild as example (chromium-72.0.3626.28-r1.ebuild), at line 519 the ebuild adds sse2, mmx and fpmath=sse if the architecture is x86 by executing: append-flags -msse2 -mfpmath=sse -mmmx Then, later in the same ebuild, at line 541, these added flags and also the original CFLAGS are removed by the strip-flags call. strip-flags is called if the custom-cflags USE flag is not set. (Which it usually isn't.) This results in the compile error of audio_bus.cc later in the process, since all mmx and sse flags now are not present. Commenting out strip-flags line in the ebuild makes Chromium install just fine. Reproducible: Always Steps to Reproduce: 1. Emerge chromium for i686 arch without setting custom-cflags Actual Results: ninja: build stopped: subcommand failed. Expected Results: Chromium installed successfully In our opinion, the ebuild should not try to be to "smart" in handling compile flags, but leave that up to the user to set those that should be necessary to make it work. A warning for missing flags like those needed for sse/mmx support would be more appropriate.
Who is "we"? Is this bug report from the Borg collective? ;-) > Then, later in the same ebuild, at line 541, these added flags and also the original CFLAGS are removed by the strip-flags call. Sounds like I need to move the x86 CFLAGS logic after the strip-flags call. > In our opinion, the ebuild should not try to be to "smart" in handling compile flags, but leave that up to the user to set those that should be necessary to make it work. I suspect you have little experience in dealing with Gentoo bug reports. Gentoo users do all sorts of crazy things, and that makes my job more difficult. Calling strip-flags makes that a bit less difficult.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=91f2491c60e83b240a777abb7630fa81a65ecc2a commit 91f2491c60e83b240a777abb7630fa81a65ecc2a Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2019-01-05 05:07:02 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2019-01-05 05:07:02 +0000 www-client/chromium: call strip-flags before appending flags Closes: https://bugs.gentoo.org/674500 Package-Manager: Portage-2.3.53_p6, Repoman-2.3.12_p37 Signed-off-by: Mike Gilbert <floppym@gentoo.org> www-client/chromium/chromium-71.0.3578.98.ebuild | 35 +++++++++++----------- .../chromium/chromium-72.0.3626.28-r1.ebuild | 35 +++++++++++----------- 2 files changed, 36 insertions(+), 34 deletions(-)
