Summary: | www-client/chromium-127.0.6533.72 fails to compile with lto error | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | André Malo <nd> |
Component: | Current packages | Assignee: | Chromium Project <chromium> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chrboesch, kaikaikai, kangie, nd, zsojka |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log (xz) |
Description
André Malo
2024-07-27 20:17:23 UTC
Created attachment 898416 [details]
build.log (xz)
Same error without any changes to prior settings. (In reply to chrboesch@datexp.net from comment #2) > Same error without any changes to prior settings. My workaround: In the directory "/etc/portage/package.use" a file "chromium" with entry "www-client/chromium -official -lto" That will not be sufficient, and you should probably re-enable "official" for .88. LTO now comes from CFLAGS, so package.env will be your best bet. I'm still not sure what's causing this under some configurations, I suspect a USE that I haven't tried yet. (In reply to Matt Jolly from comment #4) > That will not be sufficient, and you should probably re-enable "official" > for .88. > > LTO now comes from CFLAGS, so package.env will be your best bet. > > I'm still not sure what's causing this under some configurations, I suspect > a USE that I haven't tried yet. I deactivated it again because it works with 127.0.6533.88. From my point of view the ticket is solved. (In reply to chrboesch@datexp.net from comment #5) > (In reply to Matt Jolly from comment #4) > > That will not be sufficient, and you should probably re-enable "official" > > for .88. > > > > LTO now comes from CFLAGS, so package.env will be your best bet. > > > > I'm still not sure what's causing this under some configurations, I suspect > > a USE that I haven't tried yet. > > I deactivated it again because it works with 127.0.6533.88. From my point of > view the ticket is solved. I am hitting this with www-client/chromium-127.0.6533.88 , but I have non-standard CFLAGS (lto + -O3) -Werror=odr -Werror=strict-aliasing -O3 -pipe -flto=auto -march=native -fno-stack-protector (In reply to Zdenek Sojka from comment #6) > (In reply to chrboesch@datexp.net from comment #5) > > (In reply to Matt Jolly from comment #4) > > > That will not be sufficient, and you should probably re-enable "official" > > > for .88. > > > > > > LTO now comes from CFLAGS, so package.env will be your best bet. > > > > > > I'm still not sure what's causing this under some configurations, I suspect > > > a USE that I haven't tried yet. > > > > I deactivated it again because it works with 127.0.6533.88. From my point of > > view the ticket is solved. > > I am hitting this with www-client/chromium-127.0.6533.88 , but I have > non-standard CFLAGS (lto + -O3) > > -Werror=odr -Werror=strict-aliasing -O3 -pipe -flto=auto -march=native > -fno-stack-protector And even with very basic cflags: -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -O2 -pipe -flto=auto (I've even removed -march=native) ... FAILED: character_data_generator "python3.12" "../../build/toolchain/gcc_link_wrapper.py" --output="./character_data_generator" -- x86_64-pc-linux-gnu-clang++-18 -fuse-ld=lld -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl ,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,--thinlto-cache-dir=thinlto-cache -Wl,--thinlto-cache-policy=cache_size=10\%:cache_size_bytes=40g:cache_size_files=100000 -flto =thin -Wl,--thinlto-jobs=all -Wl,-mllvm,-import-instr-limit=30 -Wl,-mllvm,-disable-auto-upgrade-debug-info -Wl,-mllvm,-inlinehint-threshold=360 -fwhole-program-vtables -Wl,--undefined-versio n -Wl,--no-call-graph-profile-sort -no-canonical-prefixes -Wl,-z,defs -Wl,--as-needed -nostdlib++ -Wl,--lto-O0 -rdynamic -pie -Wl,--disable-new-dtags prebuilt_rustc_sysroot/lib/rustlib/x86_6 4-unknown-linux-gnu/lib/libstd.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if.rl ib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore.rlib prebuilt_rustc_sysro ot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgetopts.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknow n-linux-gnu/lib/liblibc.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_abort.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwi nd.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect.rlib prebuilt_rus tc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libtest.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunicode_width.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_ 64-unknown-linux-gnu/lib/libunwind.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/liba dler.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr.rlib prebuilt_rustc_sysroot/ lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide.rlib prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject.rlib -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-reloc s -Wl,--undefined-version -o "./character_data_generator" -Wl,--start-group @"./character_data_generator.rsp" -Wl,--end-group -ldl -lpthread -lrt -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -licui18n -licuuc -licudata -latomic -lz -Wl,--start-group obj/third_party/rust/cxx/v1/lib/libcxx_lib.rlib obj/third_party/rust/serde_json_lenient/v0_2/wrapper/libthird_uparty_sru st_sserde_ujson_ulenient_sv0_u2_swrapper_cwrapper.rlib obj/third_party/rust/serde/v1/lib/libserde_lib.rlib obj/third_party/rust/serde_json_lenient/v0_2/lib/libserde_json_lenient_lib.rlib obj /third_party/rust/itoa/v1/lib/libitoa_lib.rlib obj/third_party/rust/ryu/v1/lib/libryu_lib.rlib obj/build/rust/chromium_prelude/libchromium.rlib -Wl,--end-group ld.lld: error: inconsistent LTO Unit splitting (recompile with -fsplit-lto-unit) x86_64-pc-linux-gnu-clang++-18: error: linker command failed with exit code 1 (use -v to see invocation) "Good" news. I've started hitting this too. I'm not sure why it's happening yet, but at least I can reproduce. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=213cf8bacaee8816cd161bf4f48879befede462d commit 213cf8bacaee8816cd161bf4f48879befede462d Author: Matt Jolly <kangie@gentoo.org> AuthorDate: 2024-08-07 10:26:20 +0000 Commit: Matt Jolly <kangie@gentoo.org> CommitDate: 2024-08-07 14:40:32 +0000 www-client/chromium: add 127.0.6533.99 Attempt to detect and `die` if ld is 'mold'. This is not supported and causes builds to fail when targets are linked. Bug: https://bugs.gentoo.org/936858 Bug: https://bugs.gentoo.org/937510 Closes: https://bugs.gentoo.org/936792 Signed-off-by: Matt Jolly <kangie@gentoo.org> www-client/chromium/Manifest | 2 + www-client/chromium/chromium-127.0.6533.99.ebuild | 1480 +++++++++++++++++++++ 2 files changed, 1482 insertions(+) Thank you for the fix, but I don't have mold installed: $ emerge -vp mold These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 5.98 s (backtrack: 0/20). [ebuild N ] dev-libs/blake3-1.5.1::gentoo 237 KiB [ebuild N ] dev-libs/mimalloc-2.1.2:0/2::gentoo USE="-hardened -test -valgrind" ABI_X86="32 (64) (-x32)" 1137 KiB [ebuild N ] sys-devel/mold-2.31.0::gentoo 9797 KiB It seems ld.lld tries to link objects (system libraries) compiled by gcc (with gcc LTO), with chromium objects compiled by llvm (with llvm LTO); all files are compiled with thin-lto only with format appropriate for the given compiler. Can that ever work? (In reply to Zdenek Sojka from comment #11) > It seems ld.lld tries to link objects (system libraries) compiled by gcc > (with gcc LTO), with chromium objects compiled by llvm (with llvm LTO); all > files are compiled with thin-lto only with format appropriate for the given > compiler. Can that ever work? Please ignore this. I will try the new ebuild later. (In reply to Larry the Git Cow from comment #9) > The bug has been closed via the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=213cf8bacaee8816cd161bf4f48879befede462d > > commit 213cf8bacaee8816cd161bf4f48879befede462d > Author: Matt Jolly <kangie@gentoo.org> > AuthorDate: 2024-08-07 10:26:20 +0000 > Commit: Matt Jolly <kangie@gentoo.org> > CommitDate: 2024-08-07 14:40:32 +0000 > > www-client/chromium: add 127.0.6533.99 > > Attempt to detect and `die` if ld is 'mold'. > > This is not supported and causes builds to fail > when targets are linked. > > Bug: https://bugs.gentoo.org/936858 > Bug: https://bugs.gentoo.org/937510 > Closes: https://bugs.gentoo.org/936792 > Signed-off-by: Matt Jolly <kangie@gentoo.org> > > www-client/chromium/Manifest | 2 + > www-client/chromium/chromium-127.0.6533.99.ebuild | 1480 > +++++++++++++++++++++ > 2 files changed, 1482 insertions(+) I have no clue how this helped, but it seems I am able to build chromium-127.0.6533.99 with LTO enabled. Thank you |