Closed MaxIhlenfeldt closed 11 months ago
I think it makes sense to work on M116, yes. It'll have to be done, and I think it's not feasible to continue supporting clang 12.
I'll keep trying to reach @kraj in the meantime.
I'll start working on it, then!
Short progress update: after a few patches (mostly additions to existing ones) mickledore builds now, kirkstone fails in the final linking step.
Can you post the link failure (Kirkstone)?
Can you post the link failure (Kirkstone)?
Sure, here you go:
FAILED: chrome
"python3" "../../build/toolchain/gcc_link_wrapper.py" --output="./chrome" -- aarch64-oe-linux-clang++ -target aarch64-oe-linux -mcpu=cortex-a72 -march=armv8-a+crc -mbranch-protection=standard -mlittle-endian -Qunused-arguments --sysroot=/home/max/build/builds/ci-chromium-wayland-rpi4-kirkstone/tmp-glibc/work/cortexa72-oe-linux/chromium-ozone-wayland/116.0.5845.140-r0/recipe-sysroot -Wl,--version-script=../../build/linux/chrome.map -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,-mllvm,-instcombine-lower-dbg-declare=0 -flto=thin -Wl,--thinlto-jobs=32 -Wl,--thinlto-cache-dir=thinlto-cache -Wl,--thinlto-cache-policy=cache_size=10\%:cache_size_bytes=40g:cache_size_files=100000 -Wl,-mllvm,-import-instr-limit=30 -fwhole-program-vtables -Wl,--undefined-version -Wl,--no-call-graph-profile-sort -Wl,-mllvm,-enable-machine-outliner=never -Wl,-O2 -Wl,--gc-sections -rdynamic -Wl,-z,defs -Wl,--as-needed -pie -Wl,--disable-new-dtags -Wl,--lto-O2 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fmacro-prefix-map=/home/max/build/builds/ci-chromium-wayland-rpi4-kirkstone/tmp-glibc/work/cortexa72-oe-linux/chromium-ozone-wayland/116.0.5845.140-r0=/usr/src/debug/chromium-ozone-wayland/116.0.5845.140-r0 -fdebug-prefix-map=/home/max/build/builds/ci-chromium-wayland-rpi4-kirkstone/tmp-glibc/work/cortexa72-oe-linux/chromium-ozone-wayland/116.0.5845.140-r0=/usr/src/debug/chromium-ozone-wayland/116.0.5845.140-r0 -fdebug-prefix-map=/home/max/build/builds/ci-chromium-wayland-rpi4-kirkstone/tmp-glibc/work/cortexa72-oe-linux/chromium-ozone-wayland/116.0.5845.140-r0/recipe-sysroot= -fdebug-prefix-map=/home/max/build/builds/ci-chromium-wayland-rpi4-kirkstone/tmp-glibc/work/cortexa72-oe-linux/chromium-ozone-wayland/116.0.5845.140-r0/recipe-sysroot-native= -stdlib=libc++ -o "./chrome" -Wl,--start-group @"./chrome.rsp" -Wl,--end-group -latomic -ldl -lpthread -lrt -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -latk-1.0 -latk-bridge-2.0 -lgio-2.0 -ldbus-1 -lresolv -lexpat -ljpeg -luuid -ldrm -lxkbcommon -latspi -lpci -lffi -lgbm -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lcairo -lasound -lFLAC -lm -lz -lxslt -lxml2
aarch64-oe-linux-ld.lld: error: undefined symbol: unsigned long cc::PaintOpWriter::SerializedSize<unsigned long>()
>>> referenced by paint_op_writer.h:157 (../../cc/paint/paint_op_writer.h:157)
>>> thinlto-cache/llvmcache-BCD5C8265F54A91D49A9B80C31DFF57A304A7B55:(cc::(anonymous namespace)::SafeSizeForImage(cc::ClientImageTransferCacheEntry::Image const&))
>>> referenced by paint_op_writer.h:157 (../../cc/paint/paint_op_writer.h:157)
>>> thinlto-cache/llvmcache-BCD5C8265F54A91D49A9B80C31DFF57A304A7B55:(cc::(anonymous namespace)::SafeSizeForImage(cc::ClientImageTransferCacheEntry::Image const&))
>>> referenced by paint_op_writer.h:157 (../../cc/paint/paint_op_writer.h:157)
>>> thinlto-cache/llvmcache-BCD5C8265F54A91D49A9B80C31DFF57A304A7B55:(cc::(anonymous namespace)::SafeSizeForImage(cc::ClientImageTransferCacheEntry::Image const&))
>>> referenced 1 more times
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
I'll try to look into the error today. If you have any suspicions for possible causes, please let me know :)
I don't know why, but it seems clang 14 fails to correctly generate the T = size_t
instantiation of cc::PaintOpWriter::SerializedSize<T>()
. Explicitly providing it as a specialization fixes the linking error.
dunfell is currently building, but I'm optimistic it'll build as well given that it also uses clang 14.
dunfell also builds fine, I'll get a PR ready tomorrow.
https://chromereleases.googleblog.com/2023/08/stable-channel-update-for-desktop_15.html
Currently blocked on #741 being merged.
@rakuco do you think it makes sense to start working on this update already, given that the only thing preventing the 115 PR from being merged is that we haven't figured out yet how to integrate your
dunfell-clang14
branch intometa-clang
?