| Message ID | 20250801042242.3076232-3-raj.khem@gmail.com |
|---|---|
| State | Accepted, archived |
| Commit | 26a293d639ab88db84137e9df1d608dfa15aba5f |
| Headers | show |
| Series | [1/7] toolchain/clang-native: Set BUILD_LDFLAGS instead of LDFLAGS | expand |
On Fri, 1 Aug 2025 at 06:22, Khem Raj via lists.openembedded.org <raj.khem=gmail.com@lists.openembedded.org> wrote: > > Unlike GNU ld, LLD defaults to erroring about undefined version symbols > add commandline parameter to sush lld here > > Fixes > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'crypt_gensalt_r' failed: symbol not defined > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt' failed: symbol not defined > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_gensalt' failed: symbol not defined > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_gensalt_r' failed: symbol not defined > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_r' failed: symbol not defined > | x86_64-yoesdk-linux-clang: error: linker command failed with exit code 1 (use -v to see invocation) > +LDFLAGS:append:toolchain-clang = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-lld', ' -Wl,--undefined-version', '', d)}" Wait. Why is there an undefined symbol error in the first place? Shouldn't we address the error, rather than silence it? The same question stands for similar patches for libtirpc, gzip and binutils-cross-canadian. Alex
On Thu, Aug 7, 2025 at 2:57 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > On Fri, 1 Aug 2025 at 06:22, Khem Raj via lists.openembedded.org > <raj.khem=gmail.com@lists.openembedded.org> wrote: > > > > Unlike GNU ld, LLD defaults to erroring about undefined version symbols > > add commandline parameter to sush lld here > > > > Fixes > > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'crypt_gensalt_r' failed: symbol not defined > > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt' failed: symbol not defined > > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_gensalt' failed: symbol not defined > > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_gensalt_r' failed: symbol not defined > > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_r' failed: symbol not defined > > | x86_64-yoesdk-linux-clang: error: linker command failed with exit code 1 (use -v to see invocation) > > > +LDFLAGS:append:toolchain-clang = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-lld', ' -Wl,--undefined-version', '', d)}" > > Wait. Why is there an undefined symbol error in the first place? > Shouldn't we address the error, rather than silence it? LLD has stricter defaults and strict symbol versioning enforcement. LLD requires that all symbols referenced in version scripts actually exist in the object files being linked Same errors/behavior can be seen with GNU linker as well if we add -Wl,--undefined-version to LDFLAGS GNU linker chooses to be a bit lenient with defaults. It is a common pattern with new vs old tools. libxcrypt uses version scripts to manage symbol versioning, but LLD requires that all symbols referenced in version scripts actually exist in the object files being linked. The symbols might be: - Conditionally compiled out based on configuration - Defined with different names/prefixes - Missing due to build configuration issues Having LLD to lower its barrier does not change the output it produces, it's the same as GNU ld, There is no difference - both .so files work identically at runtime since the symbols are exported into .dynstr sections so old binaries needing these versioned symbols can still link to them at runtime. Should the version script be fixed ? maybe, I am not sure where all libxcypt is used in legacy systems to qualify this. Current assumption is to have these symbols. This patch makes LLD behave like GNU LD does. Hope this helps you understand what's going on. Feel free to ask if you have more doubts. > > The same question stands for similar patches for libtirpc, gzip and > binutils-cross-canadian. They all have the same issue underneath. > > Alex
On Thu, 7 Aug 2025 at 22:18, Khem Raj <raj.khem@gmail.com> wrote: > Hope this helps you understand what's going on. Feel free to ask if > you have more doubts. > > > > > The same question stands for similar patches for libtirpc, gzip and > > binutils-cross-canadian. > > They all have the same issue underneath. The way you describe it, this at least merits upstream tickets, if not actual fixes. Upstreams can then decide if lld is something they care about. Alex
On Mon, Aug 11, 2025 at 1:18 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > On Thu, 7 Aug 2025 at 22:18, Khem Raj <raj.khem@gmail.com> wrote: > > > Hope this helps you understand what's going on. Feel free to ask if > > you have more doubts. > > > > > > > > The same question stands for similar patches for libtirpc, gzip and > > > binutils-cross-canadian. > > > > They all have the same issue underneath. > > The way you describe it, this at least merits upstream tickets, if not > actual fixes. Upstreams can then decide if lld is something they care > about. > Its in plan. I have reported it for libxcrypt. https://github.com/besser82/libxcrypt/issues/213 Others are also in works. > Alex
diff --git a/meta/recipes-core/libxcrypt/libxcrypt.inc b/meta/recipes-core/libxcrypt/libxcrypt.inc index 77fec832348..10f6cd921d8 100644 --- a/meta/recipes-core/libxcrypt/libxcrypt.inc +++ b/meta/recipes-core/libxcrypt/libxcrypt.inc @@ -24,3 +24,5 @@ API = "--disable-obsolete-api" EXTRA_OECONF += "${API}" BBCLASSEXTEND = "native nativesdk" + +LDFLAGS:append:toolchain-clang = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-lld', ' -Wl,--undefined-version', '', d)}"
Unlike GNU ld, LLD defaults to erroring about undefined version symbols add commandline parameter to sush lld here Fixes | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'crypt_gensalt_r' failed: symbol not defined | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt' failed: symbol not defined | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_gensalt' failed: symbol not defined | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_gensalt_r' failed: symbol not defined | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_r' failed: symbol not defined | x86_64-yoesdk-linux-clang: error: linker command failed with exit code 1 (use -v to see invocation) Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/recipes-core/libxcrypt/libxcrypt.inc | 2 ++ 1 file changed, 2 insertions(+)