Gentoolto: enable LTO for chromium

[Hello71]

it is enabled for official builds upstream since 2016, but Gentoo does not use it, even if -flto is specified.

[wolfwood]

I've been building successfully with USE custom-cflags, which should disable the flag stripping, although I haven't verified that LTO is being enabled

[InBetweenNames]

Anyone willing to do a PR? I don't use Chromium myself and I remember it took forever to compile.

[wolfwood]

@InBetweenNames is there a way to confirm a binary has been LTO'd or do you look at the build logs?

[InBetweenNames]

I just look at the build logs, however if there are any static libraries, you can objdump them to see if there are any GIMPLE symbols in the output. Example from sys-devel/flex:

~~~

qfile /usr/lib64/libfl.a
...
libyywrap.o: file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 l d .text 0000000000000000 .text
0000000000000000 l d .data 0000000000000000 .data
0000000000000000 l d .bss 0000000000000000 .bss
0000000000000000 l d .gnu.lto_.profile.2caf6e470d364625 0000000000000000 .gnu.lto_.profile.2caf6e470d364625
0000000000000000 l d .gnu.lto_.icf.2caf6e470d364625 0000000000000000 .gnu.lto_.icf.2caf6e470d364625
0000000000000000 l d .gnu.lto_.jmpfuncs.2caf6e470d364625 0000000000000000 .gnu.lto_.jmpfuncs.2caf6e470d364625
...
...
~~~

The .gnu.lto_. part is the GIMPLE from GCC. However, shared objects won't have any GIMPLE associated with them, so executables and .so files won't look any different.

[Hello71]

but if they're unstripped and you're lucky you can find LTO function fragments.

[Hello71]

1. install sys-devel/lld
2. set EXTRA_GN="thin_lto_enable_optimizations=true use_lld=true use_thin_lto=true"

alternatively, simply:

1. set sys-devel/chromium USE=custom-cflags

[Hello71]

OK, I finally built it successfully. this does work. note that it significantly increases CPU, RAM, and disk usage during build. it (very very approximately) doubles each of these.

[InBetweenNames]

@Hello71, were you able to just use custom-cflags or did it require more in-depth workarounds?

[Hello71]

I didn't use custom-cflags, I used the gn options. I assume this is better supported upstream.

[funghetto]

Ye I opened a bug report about that sever months ago because I noticed that in benchmark Chromium compiled in gentoo was slower than binary Chrome or Arch linux Chromium.
The problems are that you should use latest clang, LLD and do an official_build or enable the LTO flags, also with LTO it takes much longer and you'll probably need a very strong/server machine, at least 16GB of ram.

I also tried to compile Chromium with GCC using fedora's patches but it was even slower in benchmarks.

[sjnewbury]

@funghetto How much slower, and what was slower, JS? I only compile Chromium with GCC and have had no issue with performance with custom cflags.

[funghetto]

I've used mainly Speedometer (https://browserbench.org/Speedometer2.0/) and there was like a 15%-20% performance drop there.

[mateuszmandera]

USE=custom-cflags compilation works for me by changing the compiler to clang, linker to lld and changing -flto=n (which isn't a valid option in clang) to -flto. Is that something to make a PR for, or do we avoid replacing gcc with clang (since I haven't seen this as something suggested anywhere nor noticed such workarounds)? @InBetweenNames

[ms178]

While it is not about Chromium but Firefox, there is a great blog post of a GCC developer with some interesting data points on the Clang vs. GCC debate: http://hubicka.blogspot.com/2018/12/firefox-64-built-with-gcc-and-clang.html

[ionenwks]

While it is not about Chromium but Firefox, there is a great blog post of a GCC developer with some interesting data points on the Clang vs. GCC debate: http://hubicka.blogspot.com/2018/12/firefox-64-built-with-gcc-and-clang.html

For Firefox at this point I've given up and switched to clang+lto+pgo mostly because it's more tested (being default). Firefox source code has a decent amount of ambiguous code that easily breaks with many optimizations from one version to the next and it's often subtle issues rather than a segfault, and most are long-standing known issues that aren't getting fixed anytime soon, only gcc 6 is officially supported too.

Shame the ebuild doesn't have a flag for pgo right now though, but it's just about setting MOZ_PGO=1.

Even if gcc+lto+pgo performs better, I'm not sure I want to deal with this anymore unless it gets some official support effort.

[ms178]

In the short term, you can use his binary instead. :)

I have uploaded a binary build with GCC 8, with link-time optimization and profile feedback. If your curiosity exceeds the fear of running random binaries from the net, you are welcome to try it out. It is built from Firefox 64 release. You can compare it to the official build and build provided by your favourite distro.

[perfect7gentleman]

I've managed to builf Chromium with LTO

www-client/chromium-76.0.3809.100::gentoo was built with the following:
USE="cups custom-cflags jumbo-build (pic) proprietary-codecs pulseaudio suid system-ffmpeg system-icu system-libvpx tcmalloc -closure-compile -component-build -gnome-keyring -hangouts -kerberos (-selinux) -widevine" L10N="ru -am -ar -bg -bn -ca -cs -da -de -el -en-GB -es -es-419 -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt-BR -pt-PT -ro -sk -sl -sr -sv -sw -ta -te -th -tr -uk -vi -zh-CN -zh-TW"
CFLAGS="-march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fno-plt -fno-stack-protector -ftree-vectorize -s"
CXXFLAGS="-march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fno-plt -fno-stack-protector -ftree-vectorize -s -Wno-pedantic -Wno-unused-result -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-deprecated-declarations -Wno-return-type -Wno-parentheses -Wno-misleading-indentation -Wno-attributes -Wno-subobject-linkage -Wno-ignored-attributes -Wno-ignored-attributes -Wno-address -Wno-dangling-else -Wno-class-memaccess -Wno-invalid-offsetof -Wno-packed-not-aligned"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs ccache config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch parallel-install pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
LDFLAGS="-Wl,-O2 -Wl,--as-needed -Wl,--sort-common -Wl,--strip-debug -flto"

[javashin]

with clang? or gcc ? @perfect7gentleman

[perfect7gentleman]

GCC.
I can't build properly working Chromium with Clang.

[javashin]

good thanks @perfect7gentleman for the info

[perfect7gentleman]

I've used some Dedian and OpenSUSE patches

[perfect7gentleman]

``` ~ $ cat /etc/portage/env/chromium
EXTRA_GN="
is_debug=false
use_goma=false
use_ozone=false
use_sysroot=false
use_openh264=false
use_libjpeg_turbo=true
use_custom_libcxx=false
use_gnome_keyring=false
use_unofficial_version_number=false
enable_vr=false
enable_nacl=false
enable_nacl_nonsfi=false
enable_swiftshader=false
enable_reading_list=false
enable_one_click_signin=false
enable_iterator_debugging=false
enable_hangout_services_extension=false
optimize_webui=true
treat_warnings_as_errors=false
linux_use_bundled_binutils=false

use_gio=false
link_pulseaudio=true
enable_widevine=false
v8_enable_backtrace=true
use_system_zlib=true
use_system_lcms2=true
use_system_libjpeg=true
use_system_freetype=true
use_system_harfbuzz=true
use_system_libopenjpeg2=true
use_jumbo_build=true
proprietary_codecs=true
ffmpeg_branding="Chrome"
fieldtrial_testing_like_official_build=true


use_aura=true
symbol_level=0
use_kerberos=false
fatal_linker_warnings=false
use_gnome_keyring=false
use_vaapi=true
use_dbus=true
enable_hevc_demuxing=true
enable_mus=true
gcc_lto=true"
CCACHE_SLOPPINESS="time_macros"

~ $ ls /etc/portage/patches/www-client/chromium
001-libcxx.patch 013-inspector._patch_ 021-widevine-locations.patch 029-openh264.patch 036-google-api-warning.patch 044-deprecated.patch 051-null-destination.patch 058-nspr.patch 102-chromium-dma-buf.patch 125-chromium-vaapi.patch
002-parallel.patch 014-gpu-timeout.patch 023-connection-message.patch 030-chromeos.patch 037-third-party-cookies.patch 045-bool-compare.patch 052-int-in-bool-context.patch 059-zlib.patch 103-chromium-buildname.patch
003-gcc_skcms_ice.patch 015-empty-array.patch 024-unrar.patch 031-perfetto.patch 038-device-notifications.patch 046-enum-compare.patch 053-vpx.patch 060-event._patch_ 104-chromium-drm.patch
004-pffffft-buildfix.patch 016-safebrowsing.patch 025-signin.patch 032-installer.patch 040-friend.patch 047-sign-compare.patch 054-icu.patch 061-ffmpeg.patch 105-chromium-sandbox-pie.patch
009-mojo.patch 017-sequence-point.patch 026-android.patch 033-font-tests.patch 041-printf.patch 048-initialization.patch 055-gtk2.patch 062-jsoncpp._patch_ 107-chromium-system-libusb.patch
011-ps-print.patch 018-jumbo-namespace.patch 027-fuzzers.patch 034-swiftshader.patch 042-attribute.patch 049-unused-typedefs.patch 056-jpeg.patch 063-openjpeg.patch 109-gcc-lto-rsp-clobber.patch
012-as-needed.patch 019-template-export.patch 028-tracing.patch 035-welcome-page.patch 043-multichar.patch 050-unused-functions.patch 057-lcms.patch 064-convertutf.patch 110-gcc-enable-lto.patch
```

[ElDavoo]

On the other hand, I can't compile chromium with gcc 9 and lto:

[4259/19949] rm -f obj/third_party/blink/public/mojom/libweb_feature_mojo_bindings_mojom.a && "x86_64-pc-linux-gnu-ar" -T -r -c -s -D obj/third_party/blink/public/mojom/libweb_feature_mojo_bindings_mojom.a @"obj/third_party/blink/public/mojom/libweb_feature_mojo_bindings_mojom.a.rsp"
[4260/19949] x86_64-pc-linux-gnu-g++ -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -rdynamic -pie -Wl,--disable-new-dtags -Wl,-O1 -Wl,--as-needed -O2 -march=native -falign-functions=32 -O3 -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=1 -fuse-linker-plugin -o "./character_data_generator" -Wl,--start-group @"./character_data_generator.rsp"  -Wl,--end-group  -latomic -ldl -lpthread -lrt -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -licui18n -licuuc -licudata
FAILED: character_data_generator 
x86_64-pc-linux-gnu-g++ -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -rdynamic -pie -Wl,--disable-new-dtags -Wl,-O1 -Wl,--as-needed -O2 -march=native -falign-functions=32 -O3 -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=1 -fuse-linker-plugin -o "./character_data_generator" -Wl,--start-group @"./character_data_generator.rsp"  -Wl,--end-group  -latomic -ldl -lpthread -lrt -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -licui18n -licuuc -licudata
during IPA pass: pta
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.gentoo.org/> for instructions.
lto-wrapper: fatal error: x86_64-pc-linux-gnu-g++ returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
 * ERROR: www-client/chromium-79.0.3945.29::gentoo failed (compile phase):
 *   ninja -v -j1 -l1 -C out/Release v8_context_snapshot_generator failed

[ElDavoo]

the problem was actually -fipa-pta so I disabled and tried to compile without it.
ICE (maybe on the same file too) in the Graphite stage.
I'm now trying to build it without Graphite...

[elsandosgrande]

Hmm... That's interesting. I have never built Chrome(ium) though, since LibreOffice and QtWebengine take long enough already and my primary browser is Firefox Nightly.

[ElDavoo]

Thing is tests are more difficult due to the big nature of this package. A single test can take 1-2 days if you compile with a low powered machine.
Anyway, no graphite allowed me to get further, but then I got this error.

[7522/19949] python ../../tools/protoc_wrapper/protoc_wrapper.py crx3.proto --protoc ./protoc --proto-in-dir ../../components/crx_file --cc-out-dir gen/components/crx_file --py-out-dir pyproto/components/crx_file
FAILED: pyproto/components/crx_file/crx3_pb2.py gen/components/crx_file/crx3.pb.h gen/components/crx_file/crx3.pb.cc 
python ../../tools/protoc_wrapper/protoc_wrapper.py crx3.proto --protoc ./protoc --proto-in-dir ../../components/crx_file --cc-out-dir gen/components/crx_file --py-out-dir pyproto/components/crx_file
terminate called after throwing an instance of 'std::system_error'
  what():  Unknown error -1
Protoc has returned non-zero status: -6

Since this error does not give any clue on what is going wrong, I'm now trying to compile with USE="-custom-cflags".

[barolo]

Thing is tests are more difficult due to the big nature of this package. A single test can take 1-2 days if you compile with a low powered machine.
Anyway, no graphite allowed me to get further, but then I got this error.

[7522/19949] python ../../tools/protoc_wrapper/protoc_wrapper.py crx3.proto --protoc ./protoc --proto-in-dir ../../components/crx_file --cc-out-dir gen/components/crx_file --py-out-dir pyproto/components/crx_file
FAILED: pyproto/components/crx_file/crx3_pb2.py gen/components/crx_file/crx3.pb.h gen/components/crx_file/crx3.pb.cc 
python ../../tools/protoc_wrapper/protoc_wrapper.py crx3.proto --protoc ./protoc --proto-in-dir ../../components/crx_file --cc-out-dir gen/components/crx_file --py-out-dir pyproto/components/crx_file
terminate called after throwing an instance of 'std::system_error'
  what():  Unknown error -1
Protoc has returned non-zero status: -6

Since this error does not give any clue on what is going wrong, I'm now trying to compile with USE="-custom-cflags".

I could test it for you, it takes hour or so to build but I gave up on compiling with gcc. Chromium uses clang specific optimizations/patches which result in significant performance differences [ 20%~ ]

[ElDavoo]

Chromium uses clang specific optimizations/patches which result in significant performance differences [ 20%~ ]

Can you demonstrate that? If that's true, we don't we force chromium to use clang as compiler?

[barolo]

Chromium uses clang specific optimizations/patches which result in significant performance differences [ 20%~ ]

Can you demonstrate that? If that's true, we don't we force chromium to use clang as compiler?

Chrome/ium uses clangs -fwhole-program-vtables for performance boost amongst other things,
"Skia contains SSE and AVX optimized rendering routines which are written using Clang only vector extensions." From Honza Hubickas blog [ GCC dev ]
If you need more stuff I'll link it later

As to why it isn't used? Nobody cares about compiling chromium from source with the exception of niche Gentoo user. Gentoo isn't particularly bleeding edge at its core nor it cares about chromium, clang that much. There are talks but it moves at snail's pace

I've seen some ebuilds in overlays with clang as an option but most of them disappeared recently, chromium is a fast moving target and stuff around it adapts slowly

Firefox upstream is also compiled with clang, just FYI, and clang version had double rendering performance for some time [ which was fixed/patched ]

[automorphism88]

Chrome/ium uses clangs -fwhole-program-vtables for performance boost amongst other things,
"Skia contains SSE and AVX optimized rendering routines which are written using Clang only vector extensions." From Honza Hubickas blog [ GCC dev ]

After reading about this I decided to give clang another try. I am able to build chromium fine with GCC 9.2 using LTO, but when I attempt to use clang, it fails very early in the build process, and I haven't been able to figure out why. Here is the error I get:

[80/808] clang++ -pie -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -fuse-ld=lld -Wl,--icf=all -Wl,--color-diagnostics -flto=thin -Wl,--thinlto-jobs=8 -Wl,--thinlto-cache-dir=thinlto-cache -Wl,--thinlto-cache-policy,cache_size=10\%:cache_size_bytes=10g:cache_size_files=100000 -Wl,--lto-O2 -fwhole-program-vtables -rdynamic -pie -Wl,--disable-new-dtags -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-z,relro -Wl,-z,now -flto=thin -O3 -pipe -march=bdver4 -fstack-check -o "./bytecode_builtins_list_generator" -Wl,--start-group @"./bytecode_builtins_list_generator.rsp"  -Wl,--end-group  -latomic -ldl -lpthread -lrt
[81/808] clang++ -pie -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -fuse-ld=lld -Wl,--icf=all -Wl,--color-diagnostics -flto=thin -Wl,--thinlto-jobs=8 -Wl,--thinlto-cache-dir=thinlto-cache -Wl,--thinlto-cache-policy,cache_size=10\%:cache_size_bytes=10g:cache_size_files=100000 -Wl,--lto-O2 -fwhole-program-vtables -rdynamic -pie -Wl,--disable-new-dtags -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-z,relro -Wl,-z,now -flto=thin -O3 -pipe -march=bdver4 -fstack-check -o "./gen-regexp-special-case" -Wl,--start-group @"./gen-regexp-special-case.rsp"  -Wl,--end-group  -latomic -ldl -lpthread -lrt -licui18n -licuuc -licudata
[82/808] python ../../v8/tools/run.py ./gen-regexp-special-case gen/v8/src/regexp/special-case.cc
[83/808] touch obj/v8/run_gen-regexp-special-case.stamp
[84/808] python ../../v8/tools/run.py ./bytecode_builtins_list_generator gen/v8/builtins-generated/bytecodes-builtins-list.h
FAILED: gen/v8/builtins-generated/bytecodes-builtins-list.h 
python ../../v8/tools/run.py ./bytecode_builtins_list_generator gen/v8/builtins-generated/bytecodes-builtins-list.h
ninja: build stopped: subcommand failed.

I tried enabling FEATURES=-fail-clean and then going into the build directory and running that command manually (python ../../v8/tools/run.py ./bytecode_builtins_list_generator gen/v8/builtins-generated/bytecodes-builtins-list.h), and it worked fine, or at least returned exit status 0 and produced a file with the expected name in the expected location. So, something is different somehow in the portage environment that is making it fail, and the error only affects running bytecode_builtins_list_generator, not building it. The step that fails doesn't actually invoke either gcc or clang, so it seems strange, since even though the binary that fails to run was compiled with clang and not gcc, it runs fine outside of the portage environment, and the only changes I made to the portage environment in between were related to the switch from gcc to clang.

The changes I made to the portage environment since successfully building with gcc are as follows:
1) Enable clang, using a file in /etc/portage/env that looks like this:

CC="clang"
CXX="clang++"
LD="ld.lld"
AR="llvm-ar"
NM="llvm-nm"
RANLIB="llvm-ranlib"
CFLAGS="${CFLAGS} -flto=thin"
CXXFLAGS="${CXXFLAGS} -flto=thin"
LDFLAGS="${LDFLAGS} -flto=thin"

1. Created /etc/portage/env/www-client/chromium as follows:

EXTRA_GN="thin_lto_enable_optimizations=true use_lld=true use_thin_lto=true"

1. Enabled the custom-cflags USE flag, although the only difference it seems to make is that it prevents -O3 from being replaced by -O2. Without this USE flag, the build fails in the exact same way.

[elsandosgrande]

@automorphism88 Did you try using regular LTO (or monolithic, as the Clang documentation calls it)? I know that it's a stretch, but it couldn't hurt to try.

[automorphism88]

@automorphism88 Did you try using regular LTO (or monolithic, as the Clang documentation calls it)? I know that it's a stretch, but it couldn't hurt to try.

Just tried that and it made no difference. Exact same error.

[perfect7gentleman]

www-client/ungoogled-chromium-78.0.3904.108_p1::pf4public was built with the following:
USE="cups custom-cflags jumbo-build lld optimize-thinlto optimize-webui pdf proprietary-codecs pulseaudio system-ffmpeg system-harfbuzz system-icu system-jsoncpp system-libevent system-openh264 system-openjpeg tcmalloc thinlto vaapi -cfi -closure-compile -convert-dict -gnome -gnome-keyring -gold -kerberos -libcxx -new-tcmalloc (-selinux) -suid -system-libvpx -widevine" L10N="ru -am -ar -bg -bn -ca -cs -da -de -el -en-GB -es -es-419 -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt-BR -pt-PT -ro -sk -sl -sr -sv -sw -ta -te -th -tr -uk -vi -zh-CN -zh-TW" PYTHON_TARGETS="python2_7 python3_7 -python3_5 -python3_6"
CFLAGS="-march=native -mtune=native -O3 -pipe -fomit-frame-pointer -fno-plt -fno-stack-protector -flto=thin -Wno-unknown-warning-option -Wno-builtin-macro-redefined"
CXXFLAGS="-march=native -mtune=native -O3 -pipe -fomit-frame-pointer -fno-plt -fno-stack-protector -flto=thin -stdlib=libstdc++ -Wno-unknown-warning-option -Wno-builtin-macro-redefined"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs ccache config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch parallel-install pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
LDFLAGS="-Wl,-O3 -Wl,--as-needed -Wl,--strip-debug -flto=thin -Wl,--thinlto-jobs=7 -fuse-ld=lld -stdlib=libstdc++ -Wl,-lgcc_s -Wl,-plugin-opt,-import-instr-limit=30 -Wl,--thinlto-jobs=7"

[elsandosgrande]

@automorphism88 Oh well...

[barolo]

@automorphism88
@elsandosgrande

Why do you guys want to build chromium so badly anyway? It's a major annoyance, massive and updates often. There are binary builds for a reason plus upstream builds are compiled with all optimizations

As an exercise in lto it's fine of course

[elsandosgrande]

@barolo

1. QtWebengine is basically Chromium and it is not available in a binary form (mostly unrelated to this ticket, as I am using GCC only and QtWebengine is the back end of Chromium attached to Qt, as far as I can tell, but since you asked...).
2. I'm simply curious as to what the issue might be exactly.

[barolo]

@elsandosgrande I'm well aware of what QtWebengine is, I've opened ticked about it even.
You're right then that figuring it out would serve wider purpose.
That said, Qt + Chromium combo is doubly bad, I had LTO issues caused by both separately

[automorphism88]

@automorphism88 Oh well...

I checked dmesg and it looks like it is a segfault in libsandbox.so. That explains why the error only happens in the portage environment, and not when I try running the binary myself. I am using version 2.13 of sandbox. I might try a different version of sandbox, or rebuilding sandbox with different CFLAGS for testing, when I have a little more time to mess around with it.

@automorphism88
@elsandosgrande

Why do you guys want to build chromium so badly anyway? It's a major annoyance, massive and updates often. There are binary builds for a reason plus upstream builds are compiled with all optimizations

As an exercise in lto it's fine of course

I'm curious what binary builds you're referring to, since Gentoo doesn't offer a chromium-bin package. Google Chrome isn't the same thing and in my view it is less trustworthy from a privacy standpoint. My original reason for trying clang was that I wanted to see how long it would take to build with thin LTO, because building with gcc and LTO does take a long time. I use ccache for building chromium, which speeds things up a lot with updates, but doesn't help with linking.

[barolo]

@automorphism88 I'm not trying to be negative or pick a fight just so everyone knows, I'm simply curious.
There are upstream binary builds. Chromium defeaults aren't too great privacy wise either, there is a reason why ungoogled-chromium exists
It's only going to get worse I suspect, with their upcoming changes affecting adblocking.
( ublockOrigin is struggling to support chrome/ium right now as it just lacks some required security features as recent issue with sites tricking it had shown )

That being said, I completly understand "just wanted to see if I could do it"'
We're using Gentoo aren't we :)

[automorphism88]

@automorphism88 I'm not trying to be negative or pick a fight just so everyone knows, I'm simply curious.

Don't worry, I understood that.

There are upstream binary builds. Chromium defeaults aren't too great privacy wise either, there is a reason why ungoogled-chromium exists

Why isn't there a chromium-bin ebuild to install the official upstream binary then? Sounds like it would be just as easy as the chrome ebuild to maintain in that case. I seem to remember the work required to keep it updated being cited as the reason why there wasn't one, along with a lack of perceived need given the existence of the chrome ebuild. It's been awhile since I looked into this though.

I looked at ungoogled-chromium, but at least at the time, it lagged behind the official ebuild, and I didn't think it was worth running an outdated browser with potential security holes for. Also, when I looked at the actual patches, I recall them not being all things that I wanted or needed, and at least some of them were things that could be accomplished by simply changing configuration settings, instead of patching the source code. Bad defaults aren't a big deal if you know about and can change them.

Firefox is actually my primary browser, and privacy is one of the reasons why, but I like to keep chromium around too. That's partly why I didn't want to put too much effort into chromium, particularly if it would need to be redone for each version. Compiling it may take a long time, but it's only CPU time, not human effort.

It's only going to get worse I suspect, with their upcoming changes affecting adblocking.
( ublockOrigin is struggling to support chrome/ium right now as it just lacks some required security features as recent issue with sites tricking it had shown )

I don't care about browser adblocking, since I block ads in /etc/hosts, with a cron job that updates the blacklist daily.

That being said, I completly understand "just wanted to see if I could do it"'
We're using Gentoo aren't we :)

Yeah, for sure.

[barolo]

@automorphism88 My primary is Firefox too, built with clang since 69.x versions. As a backup I'm using falkon, which is qtwebengine/chromium based.( which I'm about to experiment on with LTO )

Hosts blocking is not enough for me, I'm using nano fork of ublockO with it's defender addon, to bypass antiadblock systems and to clean it thoroughly. With some additional annoyances and specific portals cleaners.
I might be overly sensitive to this stuff ( adds ), but I've spent my whole life without them.

[automorphism88]

Updating sandbox to 2.18 fixed the segfault, if anyone has the same issue.

[elsandosgrande]

@barolo

Side note

How do you trick sites that check for ad blockers (for example, KissA) using nano?

[barolo]

@elsandosgrande
NanoAdblocker has this companion which takes care of such scriptlets. It's the reason of Nano's exsitence.
Unsure if the site you've mentioned is included though
[ it works with ublock_O too after some configuring ]

[elsandosgrande]

@barolo I wanted to avoid mentioning the name in full, but here we go. KissAnime.

Before anybody attacks me, there is no legitimate way for me to watch a lot of anime here in Bosnia in any form, let alone in their original form.

---

Now we return to our scheduled programming.

[barolo]

@barolo I wanted to avoid mentioning the name in full, but here we go. KissAnime.

Before anybody attacks me, there is no legitimate way for me to watch a lot of anime here in Bosnia in any form, let alone in their original form.

Now we return to our scheduled programming.

I don't see any adblock popups/warning. Hopefully you'll be able to join EU soon.
Another offtopic: judging by your compilation times I've had just threw into trash bunch of PCs ten times faster than yours [ I was cleaning Uni after their upgrades ]
This world is mad

[elsandosgrande]

Well...

1. I tried my luck a few months ago and got banned for an entire week.
2. Laptop, not desktop. c05342156.pdf :cry:

[barolo]

@elsandosgrande

1. You've got banned from trying to join EU? :D
2. This thing isn't too bad, your compilation times are abnormal. You should look into zram/zswap to keep as much stuff as possible in RAM [ and you should be fine with compiling most stuff in RAM, like mesa, check Gentoo wiki about this ], as HDD is the bottleneck and compiling on it or swapping during LTOing big stuff is holding you down.

I was doing it on way worse machine some years ago

[elsandosgrande]

@barolo

1. I got banned from KissAnime.
2. Frankly, I don't see much disk activity (the swap is practically empty and it is not reading from disk all that much if at all) during Mesa linking, just approximately two gibibytes of RAM being used by the building process and my APU being pegged at a hundred percent when it is linking. MAME, on the other hand, thrashes like crazy when linking (16GiB out of twenty of swap plus 6-7GiB of RAM).

Edit

Using RAM like that would be fine if I were to not open any program during the building of packages. On the topic, how does ccache deal with changing flags and/or, at least, with these ones:

~ bash
...
CFLAGS="-O3 -march=bdver4 -pipe -pthread -fira-hoist-pressure -fira-loop-pressure -fbranch-target-load-optimize -fweb -ftracer -fsched2-use-superblocks -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=2 -fuse-linker-plugin -fuse-ld=bfd -Wall -Wextra"
...
~

[barolo]

@elsandosgrande

Believe me, you want to compile in the RAM with HDD, most stuff will be fine even with you doing someting, bigger stuff you'll need to exclude. Cache is invalidated with any flag changes.
For mesa you need compilation in RAM, for big things like MAMe you need zswap [ and exclude from compiling in RAM ]

[elsandosgrande]

@barolo All right. So, assuming that flags do not change, is it worth to put effort into ccache?

[barolo]

@elsandosgrande It is

[elsandosgrande]

@barolo Is there a quick way to get a list of all of the packages which take more than 6GiB of RAM to compile?

[barolo]

@elsandosgrande
Never seen one, check the forum. There aren't that many of them and some will warn you, that you don't have enough space. From the top of my head, MAme, Firefox, Chromiums/Qtweb, GCC, LLVM/CLANG, Libreoffice? [ not sure about this one ] Unfortunately I don't have my old exclusions, it was short and I had even less RAM [ but I was using ZRAM, with it you can compile stuff that requires more space than you have ]

[elsandosgrande]

@barolo Well, here goes nothing. Also, the article says that GCC is fine above 4GiB, especially if Objective C and Java are not selected with USE flags, which is my current setup.

[barolo]

@elsandosgrande That article wasn't written with LTO in mind which you have to take into account. Go wild, break things

[ElDavoo]

Guys! This is not a forum. Keep it around the issue please.
As @barolo suggested I trying to compile with -fwhole-program-vtables and it fails because... there is no -flto (??).
I added the flag a new file in package.cflags, with contents:
www-client/chromium *FLAGS+=-fwhole-program-vtables
I've been running a test compilation for some time and effectively looks like gentooLTO flags are not applied (this is the file that is compiling right now) :
[40/2659] clang++ -MMD -MF obj/net/net/net_string_util_icu.o.d -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_32 -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26 -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DNET_IMPLEMENTATION -DENABLE_BUILT_IN_DNS -DUSE_GIO -DUSE_SYSTEM_ZLIB=1 -DUSING_SYSTEM_ICU=1 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DUCHAR_TYPE=uint16_t -DU_IMPORT=U_EXPORT -I../.. -Igen -Igen/shim_headers/zlib_shim -Igen/shim_headers/icui18n_shim -Igen/shim_headers/icuuc_shim -I../../third_party/protobuf/src -Igen/protoc_out -I../../third_party/protobuf/src -I../../third_party/boringssl/src/include -I../../third_party/ced/src -I../../third_party/brotli/include -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -no-canonical-prefixes -Wimplicit-fallthrough -Wthread-safety -Wextra-semi -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-unneeded-internal-declaration -Wno-undefined-var-template -Wno-ignored-pragma-optimize -Wno-implicit-int-float-conversion -Wno-c99-designator -Wno-reorder-init-list -Wno-final-dtor-non-final-class -Wno-sizeof-array-div -fno-omit-frame-pointer -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -I/usr/lib64/libffi-3.3_rc2/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -Wno-shorten-64-to-32 -Wno-header-guard -I/usr/include/nss -I/usr/include/nspr -Wexit-time-destructors -I/usr/include/libmount -I/usr/include/blkid -I/usr/lib64/libffi-3.3_rc2/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -std=c++14 -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -fstack-check -O2 -fno-stack-protector -fno-stack-check -fomit-frame-pointer -march=native -falign-functions=32 -O3 -fstack-check -c ../../net/base/net_string_util_icu.cc -o obj/net/net/net_string_util_icu.o

custom-cflags USE flag is activated.
LTO_ENABLE_FLAGOMATIC=yes is in ltoworkarounds.conf.
I also tried manually writing -flto=1 in the package.cflags but looks like it gets ignored.
Does anyone have any idea?

[elsandosgrande]

LTO_ENABLE_FLAGOMATIC=yes means that flag stripping is in full swing. Maybe www-client/chromium LTO_ENABLE_FLAGOMATIC=no might work?

[ElDavoo]

I will try after this compilation ends (will take days! lol), but the wiki (and the actual ltoworkarounds.conf file) says that "yes" enables the inhibition of flag stripping
https://github.com/InBetweenNames/gentooLTO/wiki/LTOize:-overriding-flag%E2%80%90o%E2%80%90matic.eclass

[barolo]

@ElDavoo You need to enable override-flagomatic globaly via use flag for ltoize. LTO_ENABLE_FLAGOMATIC=yes is for per package exclusions

[ElDavoo]

Lol. Didn't even know ltoize has a use flag. Compiling with thin lto right now :) Thank you.
(As a comment of what I can see, looks like Chromium's "GN" build system offers a lot of flexibility on what to compile in the package and how - chromium's ebuild shoud add all of these gn's flag and convert them to portage use flags - an example of this is the choice alsa/pulseaudio :)

[jonesmz]

I'm not yet sure if this is a problem in Chromium directly, or a problem in a library that it loads, but I'm getting this new crash on my recently gentooLTO'ed systems.

I've now reproduced the problem on two different machines.

jonesmz@ymir ~ $ chromium-browser
[200949:200949:0511/145711.480678:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
[200949:200949:0511/145711.481010:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
[200949:200949:0511/145711.481143:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
[200949:200949:0511/145711.481291:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
[200949:200949:0511/145711.481438:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
[200949:200949:0511/145711.481559:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
Received signal 11 SEGV_MAPERR 000000000002

0 0x55c5671cb269 base::debug::CollectStackTrace()

1 0x55c567119456 base::debug::StackTrace::StackTrace()

2 0x55c5671ca89a base::debug::(anonymous namespace)::StackDumpSignalHandler()

3 0x55c5671cae8e base::debug::(anonymous namespace)::StackDumpSignalHandler()

4 0x7fc1c4638250 (/lib64/libpthread-2.30.so+0x1324f)

5 0x7fc1c1ef3263 _ZZSt9call_onceIZN3re24Prog6GetDFAENS1_9MatchKindEEUlPS1_E1_JS3_EEvRSt9once_flagOT_DpOT0_ENUlvE0_4_FUNEv

6 0x7fc1c46351af __pthread_once_slow

7 0x7fc1c1ef274a _ZSt9call_onceIZN3re24Prog6GetDFAENS1_9MatchKindEEUlPS1_E1_JS3_EEvRSt9once_flagOT_DpOT0_.lto_priv.0

8 0x7fc1c1ef3407 re2::Prog::SearchDFA()

9 0x7fc1c1edf32a _ZNK3re23RE25MatchERKNS_11StringPieceEmmNS0_6AnchorEPS1_i.localalias

10 0x7fc1c1ee0be1 _ZNK3re23RE27DoMatchERKNS_11StringPieceENS0_6AnchorEPmPKPKNS0_3ArgEi.localalias.lto_priv.0

11 0x55c5697296c9 AutocompleteInput::Parse()

12 0x55c56972a5e2 AutocompleteInput::ParseForEmphasizeComponents()

13 0x55c56b5bca40 OmniboxView::UpdateTextStyle()

14 0x55c5699d6270 OmniboxViewViews::EmphasizeURLComponents()

15 0x55c56b5bc1a5 OmniboxView::TextChanged()

16 0x55c5699d9fd5 OmniboxViewViews::SetWindowTextAndCaretPos()

17 0x55c56b5b7340 Received signal 11 SEGV_MAPERR 000000000002

0 0x558c86300269 OmniboxEditModel::Revert()

18 0x55c56b5bc152 base::debug::CollectStackTrace()

1 0x558c8624e456 OmniboxView::RevertAll()

19 0x55c5699dade4 base::debug::StackTrace::StackTrace()

2 0x558c862ff89a base::debug::(anonymous namespace)::StackDumpSignalHandler()

3 0x558c862ffe8e base::debug::(anonymous namespace)::StackDumpSignalHandler()

4 0x7fbdcd4e3250 (/lib64/libpthread-2.30.so+0x1324f)

5 0x7fbdcad9e263 _ZZSt9call_onceIZN3re24Prog6GetDFAENS1_9MatchKindEEUlPS1_E1_JS3_EEvRSt9once_flagOT_DpOT0_ENUlvE0_4_FUNEv

6 0x7fbdcd4e01af __pthread_once_slow

7 0x7fbdcad9d74a _ZSt9call_onceIZN3re24Prog6GetDFAENS1_9MatchKindEEUlPS1_E1_JS3_EEvRSt9once_flagOT_DpOT0_.lto_priv.0

8 0x7fbdcad9e407 re2::Prog::SearchDFA()

9 0x7fbdcad8a32a _ZNK3re23RE25MatchERKNS_11StringPieceEmmNS0_6AnchorEPS1_i.localalias

10 0x7fbdcad8bbe1 _ZNK3re23RE27DoMatchERKNS_11StringPieceENS0_6AnchorEPmPKPKNS0_3ArgEi.localalias.lto_priv.0

11 0x558c82e5688a gpu::(anonymous namespace)::StringMismatch()

12 0x558c82e56906 OmniboxViewViews::Update()

20 0x55c5699c083e LocationBarView::Update()

21 0x55c5699c2b6f gpu::GpuControlList::GLStrings::Contains()

13 0x558c82e57b2a LocationBarView::Init()

22 0x55c569a5701b gpu::GpuControlList::Conditions::Contains()

14 0x558c82e58026 ToolbarView::Init()

23 0x55c5699a9229 gpu::GpuControlList::Entry::Contains()

15 0x558c82e582d4 BrowserView::AddedToWidget()

24 0x55c568ff21a5 gpu::GpuControlList::MakeDecision()

16 0x558c82e68587 views::View::PropagateAddNotifications()

25 0x55c568ff4448 gpu::ComputeGpuFeatureInfo()

17 0x558c878fe7f0 views::View::AddChildViewAtImpl()

26 0x55c569007987 gpu::GpuInit::InitializeAndStartSandbox()

18 0x558c89d2c98c views::NonClientView::ViewHierarchyChanged()

27 0x55c568ff1ca8 content::GpuMain()

19 0x558c85b18d88 content::ContentMainRunnerImpl::Run()

20 0x558c85d5aa49 views::View::ViewHierarchyChangedImpl()

28 0x55c568ff1fd9 service_manager::Main()

21 0x558c85b16836 views::View::PropagateAddNotifications()

29 0x55c568ff4448 views::View::AddChildViewAtImpl()

30 0x55c56904ba6b content::ContentMain()

22 0x558c82252655 views::internal::RootView::SetContentsView()

31 0x55c5690001da ChromeMain

23 0x7fbdc9b1ae0b __libc_start_main

24 0x558c822524aa views::Widget::Init()

32 0x55c569bb6393 BrowserFrame::InitBrowserFrame()

33 0x55c5699ace1a _start

r8: 00007fbdc5aac900 r9: 00007fbdc5aac900 r10: 0000049c7b85b000 r11: 0000000000000000
r12: 00007ffd10732b70 r13: 00007ffd10732d6f r14: 0000000000000001 r15: 00007ffd10732c30
di: 0000000000000168 si: 00007fbdc5aab000 bp: 0000049c7b85b198 bx: 0000000000000000
dx: 00007fbdc5aabf98 ax: 00007ffd10732c40 cx: 00007fbdcad9e240 sp: 00007ffd10732b50
ip: 00007fbdcad9e263 efl: 0000000000010212 cgf: 002b000000000033 erf: 0000000000000004
trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000002
[end of stack trace]
Calling _exit(1). Core file will not be generated.
BrowserWindow::CreateBrowserWindow()

34 0x55c5698c92d3 Browser::Browser()

35 0x55c569900038 StartupBrowserCreatorImpl::OpenTabsInBrowser()

36 0x55c5699006ee StartupBrowserCreatorImpl::RestoreOrCreateBrowser()

37 0x55c569900bbc StartupBrowserCreatorImpl::DetermineURLsAndLaunch()

38 0x55c56990100d StartupBrowserCreatorImpl::Launch()

39 0x55c5698fbf68 StartupBrowserCreator::LaunchBrowser()

40 0x55c5698fc4f8 StartupBrowserCreator::ProcessLastOpenedProfiles()

41 0x55c5698fc971 StartupBrowserCreator::LaunchBrowserForLastProfiles()

42 0x55c5698fd56a StartupBrowserCreator::ProcessCmdLineImpl()

43 0x55c5698fdf61 StartupBrowserCreator::Start()

44 0x55c5670056e6 ChromeBrowserMainParts::PreMainMessageLoopRunImpl()

45 0x55c567005f4b ChromeBrowserMainParts::PreMainMessageLoopRun()

46 0x55c56473b894 content::BrowserMainLoop::PreMainMessageLoopRun()

47 0x55c564c6c856 content::StartupTaskRunner::RunAllTasksNow()

48 0x55c56473cd1a content::BrowserMainLoop::CreateStartupTasks()

49 0x55c5647404f1 content::BrowserMainRunnerImpl::Initialize()

50 0x55c56473ae28 content::BrowserMain()

51 0x55c5669e3855 content::RunBrowserProcessMain()

52 0x55c5669e3924 content::ContentMainRunnerImpl::RunServiceManager()

53 0x55c5669e3d3f content::ContentMainRunnerImpl::Run()

54 0x55c566c25a49 service_manager::Main()

55 0x55c5669e1836 content::ContentMain()

56 0x55c56311d655 ChromeMain

57 0x7fc1c0c6fe0b __libc_start_main

58 0x55c56311d4aa _start

r8: 00007fc1bcc01900 r9: 00007fc1bcc01900 r10: 00001a4872c05000 r11: 0000000000000000
r12: 00007ffcb4888b80 r13: 00007ffcb4888d7f r14: 0000000000000001 r15: 00007ffcb4888c40
di: 0000000000000168 si: 00007fc1bcc00000 bp: 00001a4872c05198 bx: 0000000000000000
dx: 00007fc1bcc00f98 ax: 00007ffcb4888c50 cx: 00007fc1c1ef3240 sp: 00007ffcb4888b60
ip: 00007fc1c1ef3263 efl: 0000000000010212 cgf: 002b000000000033 erf: 0000000000000004
trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000002
[end of stack trace]
Calling _exit(1). Core file will not be generated.
jonesmz@ymir ~ $ Received signal 11 SEGV_MAPERR 000000000002

0 0x559160d64269 base::debug::CollectStackTrace()

1 0x559160cb2456 base::debug::StackTrace::StackTrace()

2 0x559160d6389a base::debug::(anonymous namespace)::StackDumpSignalHandler()

3 0x559160d63e8e base::debug::(anonymous namespace)::StackDumpSignalHandler()

4 0x7f0fc91a1250 (/lib64/libpthread-2.30.so+0x1324f)

5 0x7f0fc6a5c263 _ZZSt9call_onceIZN3re24Prog6GetDFAENS1_9MatchKindEEUlPS1_E1_JS3_EEvRSt9once_flagOT_DpOT0_ENUlvE0_4_FUNEv

6 0x7f0fc919e1af __pthread_once_slow

7 0x7f0fc6a5b74a _ZSt9call_onceIZN3re24Prog6GetDFAENS1_9MatchKindEEUlPS1_E1_JS3_EEvRSt9once_flagOT_DpOT0_.lto_priv.0

8 0x7f0fc6a5c407 re2::Prog::SearchDFA()

9 0x7f0fc6a4832a _ZNK3re23RE25MatchERKNS_11StringPieceEmmNS0_6AnchorEPS1_i.localalias

10 0x7f0fc6a49be1 _ZNK3re23RE27DoMatchERKNS_11StringPieceENS0_6AnchorEPmPKPKNS0_3ArgEi.localalias.lto_priv.0

11 0x55915d8ba88a gpu::(anonymous namespace)::StringMismatch()

12 0x55915d8ba906 gpu::GpuControlList::GLStrings::Contains()

13 0x55915d8bbb2a gpu::GpuControlList::Conditions::Contains()

14 0x55915d8bc026 gpu::GpuControlList::Entry::Contains()

15 0x55915d8bc2d4 gpu::GpuControlList::MakeDecision()

16 0x55915d8cc587 gpu::ComputeGpuFeatureInfo()

17 0x5591623627f0 gpu::GpuInit::InitializeAndStartSandbox()

18 0x55916479098c content::GpuMain()

19 0x55916057cd88 content::ContentMainRunnerImpl::Run()

20 0x5591607bea49 service_manager::Main()

21 0x55916057a836 content::ContentMain()

22 0x55915ccb6655 ChromeMain

23 0x7f0fc57d8e0b __libc_start_main

24 0x55915ccb64aa _start

r8: 00007f0fc176a900 r9: 00007f0fc176a900 r10: 00003fb0632bb000 r11: 0000000000000000
r12: 00007ffd319652d0 r13: 00007ffd319654cf r14: 0000000000000001 r15: 00007ffd31965390
di: 0000000000000168 si: 00007f0fc1769000 bp: 00003fb0632bb198 bx: 0000000000000000
dx: 00007f0fc1769f98 ax: 00007ffd319653a0 cx: 00007f0fc6a5c240 sp: 00007ffd319652b0
ip: 00007f0fc6a5c263 efl: 0000000000010212 cgf: 002b000000000033 erf: 0000000000000004
trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000002
[end of stack trace]
Calling _exit(1). Core file will not be generated.

[jonesmz]

Sorry to be a bother, but this isn't proving simple to debug, given Chromium takes several (seeeeeeveral) hours to build.

Does anyone else have this situation, or am I doing something unusual?

[wolfwood]

i can no longer build with USE=custom-cflags due to a failure with the bundled ANGLE third-party library. without I'm building/running chromium successfully, tho it's not my main browser. Hulu wasn't working with the previous release, but seems to have corrected itself with the latest.

[jonesmz]

I've reproduced this failure with Chromium 83.0.4103.61.

I'm beginning to suspect the problem is caused by a dependency of Chromium, but I'm not sure which.

[dallenwilson]

Building with stock gentooLTO settings and custom-flags fails for me as well, but I have successfully built chromium-85.0.4183.83 with custom-cflags and an overrides file in /etc/portage/env using the template provided by @perfect7gentleman https://github.com/InBetweenNames/gentooLTO/issues/127#issuecomment-522520914

I plan on putting together an ebuild to apply those changes to all my gentoo boxes, and I'd like to see if anyone else has success with them. @InBetweenNames, if we can get a consensus on what the bare minimum is for LTO to work and get it tested widely enough to be reliable, would a PR to update sys-config/ltoize with them be welcomed?

[jonesmz]

@dallenwilson If you could link me to a file that I can drop into /etc/portage/ somewhere, I'd be happy to test for you. Note, however, that I'm still using the most recently stabilized GCC, which is 9.3 as of today. I don't use unstable compilers.

[dallenwilson]

@jonesmz Sorry for the delayed response. I'll make it available once I'm satisfied that it is likely to work for someone else. I have three Gentoo boxes to work with, two different generations of AMD and one Intel, all with somewhat different USE flags and such. Once I get it the various options pruned down to a common set that build on all of them, I'll share it.

[jonesmz]

@dallenwilson Unexpectedly, chromium now launches... but of course there have to be problems. Clipboard doesn't work :-P

jonesmz@ymir ~ $ emerge --info chromium
Portage 3.0.4 (python 3.7.8-final-0, default/linux/amd64/17.1, gcc-9.3.0, glibc-2.31-r6, 5.4.66-gentoo x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-5.4.66-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E3-1240_V2_@_3.40GHz-with-gentoo-2.7
KiB Mem:    32855652 total,  28805300 free
KiB Swap:    8388604 total,   8388604 free
Timestamp of repository gentoo: Wed, 23 Sep 2020 15:35:33 +0000
Head commit of repository gentoo: b0e87952c202395c69a653455e92cac9f086e80b

Head commit of repository jonesmz-public-overlay: f2a4eeea473f94bf0045e49ca098cd36b44b2bf3

Head commit of repository lto-overlay: a7a574dafb9aac830901daf0f884083548e34939

Head commit of repository mv: 91e621b78b79a257303a0dcb31290b54e572fdcc

Head commit of repository wsdd: 116efbeabc8f68536c93d252dfbe0897bbdc0d3b

Head commit of repository steam-overlay: 9b344386364381390a2418299779ba7fea9225c3

sh bash 5.0_p18
ld GNU ld (Gentoo 2.33.1 p2) 2.33.1
distcc 3.3.3 x86_64-pc-linux-gnu [disabled]
ccache version 3.7.11 [disabled]
app-shells/bash:          5.0_p18::gentoo
dev-java/java-config:     2.3.1::gentoo
dev-lang/perl:            5.30.3::gentoo
dev-lang/python:          2.7.18::gentoo, 3.7.8-r2::gentoo, 3.8.5::gentoo
dev-util/ccache:          3.7.11::gentoo
dev-util/cmake:           3.16.5::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.7::gentoo
sys-apps/sandbox:         2.18::gentoo
sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake:       1.16.1-r1::gentoo
sys-devel/binutils:       2.33.1-r1::gentoo, 2.34-r2::gentoo
sys-devel/gcc:            9.3.0-r1::gentoo
sys-devel/gcc-config:     2.3.1::gentoo
sys-devel/libtool:        2.4.6-r6::gentoo
sys-devel/make:           4.2.1-r4::gentoo
sys-kernel/linux-headers: 5.4-r1::gentoo (virtual/os-headers)
sys-libs/glibc:           2.31-r6::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: git
    sync-uri: git://anongit.gentoo.org/repo/sync/gentoo.git
    priority: -1000

jonesmz-public-overlay
    location: /usr/portage-overlays/jonesmz-public-overlay
    sync-type: git
    sync-uri: https://github.com/jonesmz/gentoo-overlay.git
    masters: gentoo

lto-overlay
    location: /usr/portage-overlays/lto-overlay
    sync-type: git
    sync-uri: https://github.com/InBetweenNames/gentooLTO.git
    masters: gentoo mv

mv
    location: /usr/portage-overlays/mv
    sync-type: git
    sync-uri: https://anongit.gentoo.org/git/user/mv.git
    masters: gentoo

wsdd
    location: /usr/portage-overlays/wsdd-gentoo
    sync-type: git
    sync-uri: https://github.com/christgau/wsdd-gentoo
    masters: gentoo

steam-overlay
    location: /usr/portage-overlays/steam-overlay
    sync-type: git
    sync-uri: https://github.com/anyc/steam-overlay.git
    masters: gentoo
    priority: 50

Installed sets: @archive, @creative, @desktop-applications, @lxqt, @pc-base-system, @portage, @vcs
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="@FREE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O3 -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=1 -fuse-linker-plugin -march=x86-64 -mtune=generic -O2 -pipe -ffat-lto-objects"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -pipe -O3 -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=1 -fuse-linker-plugin -march=x86-64 -mtune=generic -O2 -pipe -ffat-lto-objects"
DISTDIR="/usr/portage-distfiles"
EMERGE_DEFAULT_OPTS=" --jobs --keep-going --newuse --changed-deps --deep --tree --backtrack=3000 --complete-graph --with-bdeps=y --binpkg-respect-use=y --binpkg-changed-deps=y --changed-slot=y --usepkg=y"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg clean-logs compress-build-logs compressdebug config-protect-if-modified distlocks ebuild-locks fixlafiles installsources ipc-sandbox merge-sync multilib-strict network-sandbox news nostrip parallel-fetch parallel-install pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms split-elog split-log strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="en en_US"
MAKEOPTS="-j10"
PKGDIR="/usr/portage-packages"
PORTAGE_COMPRESS="xz"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acl acpi alsa amd64 branding bzip2 cairo cdda cdr clang crypt dbus dri dts dvd dvdr egl emboss encode exif flac gif glamor gles2 gnome-keyring gpm gstreamer gtk gtk3 gui hardened iconv icu ipv6 jpeg lcms libglvnd libnotify libtirpc mad mp3 mp4 mpeg multilib ncurses nls nptl ogg opengl openmp pam pango pcre pdf pie png policykit ppds pulseaudio qt5 readline samba sdl seccomp sound spell split-usr ssl ssp startup-notification svg systemd theora threads tiff truetype udev udisks unicode upower usb vaapi vorbis wayland widevine x264 xattr xcb xinerama xml xtpax xv xvid zeroconf zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx sse sse2 mmxext" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="coreboot efi-64 emu qemu pc" INPUT_DEVICES="libinput" KERNEL="linux" L10N="en en-US" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2 php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python2_7 python3_7" QEMU_SOFTMMU_TARGETS="arm aarch64 x86_64" QEMU_USER_TARGETS="arm aarch64 x86_64" RUBY_TARGETS="ruby25 ruby26" USERLAND="GNU" VIDEO_CARDS="vesa modesetting radeon radeonsi amdgpu" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

=================================================================
                        Package Settings
=================================================================

www-client/chromium-85.0.4183.121::gentoo was built with the following:
USE="hangouts js-type-check ozone (pic) proprietary-codecs pulseaudio system-ffmpeg system-icu tcmalloc widevine (-component-build) -cups -custom-cflags (-headless) -kerberos -ozone-wayland (-selinux) -suid (-system-libvpx)" ABI_X86="(64)" L10N="-am -ar -bg -bn -ca -cs -da -de -el -en-GB -es -es-419 -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt-BR -pt-PT -ro -ru -sk -sl -sr -sv -sw -ta -te -th -tr -uk -vi -zh-CN -zh-TW"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -Wl,-O1 -Wl,--as-needed"
CXXFLAGS="-O2 -pipe -march=x86-64 -mtune=generic -O2 -pipe -Wl,-O1 -Wl,--as-needed"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -march=x86-64 -mtune=generic -O2 -pipe"

[dallenwilson]

I ended up testing quite a few permutations of gentooLTO's default CFLAGS. I finally got chromium to build with custom-cflags set on all my machines without modifying anything at all, except for setting MAKEOPTS="-j1" and NTHREADS="1" in /etc/portage/make.conf and EXTRA_GN="gcc_lto=true" in /etc/portage/env/www-client/chromium. It launches and everything appears to work. Even the clipboard!

The error I'd been getting (terminate called after throwing an instance of 'std::system_error', always at different source files and different points in the build on every attempt) was due to the build process trying to use more threads than were available to userspace programs. I'll be investigating that next and hopefully increasing it, because building with makeopts -j1/nthreads=1 is a bit time-consuming.

[shelterx]

Always dies here for me when I try what @dallenwilson suggested (using gcc):

FAILED: pyproto/components/leveldb_proto/internal/proto/shared_db_metadata_pb2.py gen/components/leveldb_proto/internal/proto/shared_db_metadata.pb.h gen/components/leveldb_proto/internal/proto/shared_db_metadata.pb.cc
python ../../tools/protoc_wrapper/protoc_wrapper.py shared_db_metadata.proto --protoc ./protoc --proto-in-dir ../../compon          ents/leveldb_proto/internal/proto --cc-out-dir gen/components/leveldb_proto/internal/proto --py-out-dir pyproto/components          /leveldb_proto/internal/proto
terminate called after throwing an instance of 'std::system_error'

What's also weird is that it doesn't compile with clang anymore for me either, so something's changed in chromium-86.0.

[Hello71]

Always dies here for me when I try what @dallenwilson suggested (using gcc):

FAILED: pyproto/components/leveldb_proto/internal/proto/shared_db_metadata_pb2.py gen/components/leveldb_proto/internal/proto/shared_db_metadata.pb.h gen/components/leveldb_proto/internal/proto/shared_db_metadata.pb.cc
python ../../tools/protoc_wrapper/protoc_wrapper.py shared_db_metadata.proto --protoc ./protoc --proto-in-dir ../../compon          ents/leveldb_proto/internal/proto --cc-out-dir gen/components/leveldb_proto/internal/proto --py-out-dir pyproto/components          /leveldb_proto/internal/proto
terminate called after throwing an instance of 'std::system_error'

What's also weird is that it doesn't compile with clang anymore for me either, so something's changed in chromium-86.0.

you cropped out the important line of this error, but you might fix it by disabling --as-needed.

[shelterx]

Mhh I never got the lto build to work without errors, so I went with default flags now, it seems like the requirements for a standard build is higher now than before. I ran out of memory with -j4 on a a system with 8Gb of RAM,
Out of memory: Killed process 16359 (cc1plus) total-vm:3588800kB, anon-rss:2030944kB, file-rss:956kB, shmem-rss:0kB, UID:250 pgtables:4412kB oom_score_adj:0

So I suspect an lto build will require even more.

[fcsager]

I was able to get chrome to build once with gcc and this repository's lto configuration. All other attempts ended with errors like @shelterx and @dallenwilson. I don't know how I got it to build, I think it was by sheer dumb luck. However, that build was extremely buggy. It would pass Browser Speedometer 2.0 tests at an average of 12 runs per minute.

I was able to get www-client/chromium-87.0.4280.40::gentoo to build with the following env set up.

/etc/portage/package.env/chromium.conf:

CC="clang"
CXX="clang++"
AR="llvm-ar"
NM="llvm-nm"
RANLIB="llvm-ranlib"
EXTRA_GN="chrome_pgo_phase=2 is_clang=true use_lld=true thin_lto_enable_optimizations=true use_thin_lto=true"

This build is greatly out preforming the stock gcc builds I had which averaged 75-80 runs/min on Browser Speedometer 2.0. Build 87.0.4280.40 is currently posting 125+ runs/min consistently.

[fufler]

I'll be investigating that next and hopefully increasing it, because building with makeopts -j1/nthreads=1 is a bit time-consuming.

@dallenwilson Do you have any update on this? I'm facing the same problem.

The error I'd been getting (terminate called after throwing an instance of 'std::system_error', always at different source files and different points in the build on every attempt) was due to the build process trying to use more threads than were available to userspace programs.

Are you sure about the fail reason? I've tried to increase number of allowed user processes via ulimit -u unlimited but with no luck. Morever it doesn't seem to be an issue according to the number of threads in use being reported by htop during build process.

[shelterx]

I have to build with -j2 if I use gcc, I gave up on clang but I might try the settings @fcsager posted.

It's weird tho', jumbo builds when they were supported used quite a lot of more memory but I never ran OOM.
Now, a bit in the compile process some "files" eats all memory, I checked the code and they are not big at all. The compile process must be doing something extra but I have no idea what that might be.

[fufler]

I have to build with -j2 if I use gcc

Is it just -j2 or something else? I'm not able to build it even with MAKEOPTS="-j1" FEATURES="-distcc",

[shelterx]

Is it just -j2 or something else? I'm not able to build it even with MAKEOPTS="-j1" FEATURES="-distcc",

chromium.conf env file:

NTHREADS="auto" # Not sure if this is needed
MAKEOPTS="-j2"
EXTRA_GN="gcc_lto=true enable_nacl=false blink_symbol_level=0 symbol_level=0" # I don't think gcc_lto is an actual flag?

package.use:

www-client/chromium widevine jumbo-build -hangouts L10N: sv -am -ar -bg -bn -ca -cs -da -de -el -en-GB -es -es-419 -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt-BR -pt-PT -CN -zh-TW -ro -ru -sk -sl -sr -sw -ta -te -th -tr -uk -vi -zh-CN
# jumbo-build is obsolete now.

I also use ccache for chromium but it doesn't seem to help much.

[dallenwilson]

@fufler I went to NTHREADS="1"; MAKEOPTS="-j18" on my main system without problems. My other two systems failed to merge the last update, chromium-86.0.4240.198, but I haven't made time to investigate again. As to the fail reason: No, I am not sure. I based the guess on information available here, but I won't call it conclusive and did not verify it on my end.

[shelterx]

CC="clang"
CXX="clang++"
AR="llvm-ar"
NM="llvm-nm"
RANLIB="llvm-ranlib"
EXTRA_GN="chrome_pgo_phase=2 is_clang=true use_lld=true thin_lto_enable_optimizations=true use_thin_lto=true"

I had to remove chrome_pgo_phase=2 but it seems to be compiling now, running -j4 and no signs of OOM or other errors yet.

EDIT:
Successful compile! No where near OOM I think like I had when I used gcc.

[barolo]

Just a reminder, emerge --info will not show you what real flags were used.
Current chromium doesn't allow for flag changes the usual way, no matter what you'll do as they build different parts with different optimizations.
To build it with --march-native you need to pass EXTRA_GN="x64_arch=\"native\""
There's no way to force -O3 and forcing so would break everything.
It's pretty heavily optimized anyway, with pgo, thinlto and whole-vtables

[shelterx]

To build it with --march-native you need to pass EXTRA_GN="x64_arch=\"native\""

Not sure what I've done apart from using the above settings but Chromium compiles with -march=native for me. (I don't use EXTRA_GN="x64_arch="native""`)

[barolo]

@shelterx How do you know? emerge --info told you?
emerge --info just tells you that it compiled with --march-native passed to build system, not that chromium build system used it. It's the same story for many bigger packages which do own custom stuff during build.
You can just watch the compilation log for what it actually does.

[shelterx]

@barolo i see the -march=native being used flag on the source files when i compile chromium...
You can also probably use something like ps auxwww|grep native in another terminal when you compile chromium.

[sarnold]

Is there a consensus on how to properly build chromium with lto-overlay in place? What appears to be working correctly (albeit build is still in-progress) is the following with no changes to default lto-overlay flags and without enabling custom-cflags:

$ cat /etc/portage/package.env/chromium 
www-client/chromium plain-native.conf clang-bins.conf chromium.conf j3-bare.conf

$ cat /etc/portage/env/plain-native.conf 
CFLAGS="-march=native -O2 -pipe"
CXXFLAGS="${CFLAGS}"
LDFLAGS="${CFLAGS} -Wl,-O1 -Wl,--as-needed"

$ cat /etc/portage/env/clang-bins.conf 
CC="clang"
CXX="clang++"
AR="llvm-ar"
NM="llvm-nm"
RANLIB="llvm-ranlib"

$ cat /etc/portage/env/chromium.conf 
# chrome_pgo_phase=2 may be dicey
EXTRA_GN="is_clang=true use_lld=true thin_lto_enable_optimizations=true use_thin_lto=true"

[sarnold]

Note the -j3 is due to only <6 GB ram with about the same amount of swap.

[barolo]

Note the -j3 is due to only <6 GB ram with about the same amount of swap.

I have 16 GB and I'm tired of compiling chromium, it is till swapping...
I would just use bin version at this point.
There's ungoogled build from pf4public with all of your settings in use flags. For now I cannot get hw video accell to work, so I gave up [it works, enabling vulkan broke it] [ver. 91]

[sarnold]

Actually that ^^ did work, but i had to set gcc 10.x for the right cxx libs.

[barolo]

Updated ungoogled to latest, it took 8h~ to compile, entirelly in RAM on 4 core 4Ghz CPU with clang and full set of optimizations.
I don't remember it taking so much time, or am I misremembering things?

[barolo]

Also, chrome-bin is quite a bit faster than my chromium build with all optimizations turned on, at least in rendering benches, with identical gpu info in both. 640 points for chrome and 500 for chromium in Motionmark 1.2 for example.
No clue as to why.