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)
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.
Having LLD to lower its barrier does not change the output it
produces, it's the same as GNU ld
This is known issue seen with other distros e.g. NixOS upstream [1]
[1] https://github.com/besser82/libxcrypt/issues/181
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
EXTRA_OECONF += "${API}"
BBCLASSEXTEND = "native nativesdk"
+# Needed until https://github.com/besser82/libxcrypt/issues/181 is addressed
+LDFLAGS += "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-lld', '-Wl,--undefined-version', '', d)}"