I'm linking with lld by default, but still building with gcc. systemd-255 RCs present a build failure with this configuration (also attached): FAILED: src/shared/libsystemd-shared-255.so x86_64-pc-linux-gnu-gcc -o src/shared/libsystemd-shared-255.so -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libsystemd-shared-255.so -Wl,--whole-archive src/shared/libsystemd-shared-255.a src/basic/libbasic.a src/basic/libbasic-gcrypt.a s rc/libsystemd/libsystemd_static.a -Wl,--no-whole-archive -fstack-protector -march=znver1 -O2 -pipe -Wl,-O1 -Wl,--as-needed -fuse-ld=lld -Wl,--as-needed -Wl,-z,relro,-z,now src/basic/libbasic-compress.a -shared -Wl,--version-script=/var/tmp/portage/sys-apps/systemd-255_rc3/w ork/systemd-255-rc3/src/shared/libshared.sym -pthread /usr/lib64/libacl.so /usr/lib64/libblkid.so /usr/lib64/libcap.so /usr/lib64/libcrypt.so -ldl /usr/lib64/libgcrypt.so /usr/lib64/libkmod.so /usr/lib64/liblz4.so /usr/lib64/libmount.so /usr/lib64/libssl.so /usr/lib64/libcr ypto.so /usr/lib64/libpam.so -lrt /usr/lib64/libseccomp.so /usr/lib64/liblzma.so /usr/lib64/libzstd.so -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--warn-common -Wl,--gc-sections -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--warn-common -Wl,--gc-sections -lm -Wl,- -end-group -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--warn-common -Wl,--gc-sections -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--warn-common -Wl,--gc-sections -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--warn-common -Wl,--gc-sections -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--warn-common -Wl,--gc-sections ld.lld: error: src/shared/libsystemd-shared-255.a(libsystemd-shared-255.a.p/cryptsetup-util.c.o): symbol crypt_token_external_path@@ has undefined version collect2: error: ld returned 1 exit status This can be fixed by compiling systemd with clang.
Please report the issue upstream.
Will do. Somehow the build log didn't actually get attached, adding now...
This is probably an LLD 17 thing.
Created attachment 875841 [details] build.log
Upstream has added a commit that works around this for release builds: https://github.com/systemd/systemd/commit/25757715feb586d43388a035592fdedaac75c1db But now I notice that our builds are actually "developer" builds after the default was changed a few years ago: https://github.com/systemd/systemd/commit/4c8e5f442b5557a32e7d97f451d3d685f2fe26b9 So the build still fails for me even with the patch, but if I set `-Dmode=release` explicitly via MYMESONARGS, it succeeds.
> So the build still fails for me even with the patch, but if I set `-Dmode=release` explicitly via MYMESONARGS, it succeeds. PR made to change this for our distribution builds.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d9bb679dc0bbbc8bd004069590deeff8a6892178 commit d9bb679dc0bbbc8bd004069590deeff8a6892178 Author: John Helmert III <ajak@gentoo.org> AuthorDate: 2023-11-28 22:35:13 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-12-04 15:30:31 +0000 sys-apps/systemd: set release mode for live and rc's Bug: https://bugs.gentoo.org/918671 Signed-off-by: John Helmert III <ajak@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/34032 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-apps/systemd/systemd-255_rc3.ebuild | 2 ++ sys-apps/systemd/systemd-255_rc4.ebuild | 2 ++ sys-apps/systemd/systemd-9999.ebuild | 2 ++ 3 files changed, 6 insertions(+)
Seems fixed for me now, thanks!
