Loading the POSIX module after loading others in perl causes errors to get hidden. The
resulting build failures are obtuse and hard to debug. We see this quite often when
we upgrade glibc but not uninative and there are symbol mismatches.
Add a quick test to the start of configure which tests perl operates correct and shows
a much more obvious error if it isn't since the POSIX module doesn't have to reload.
An example of the new error is:
| Can't load 'XXX/buildtools-extended-tarball/1.0-r0/testimage-sdk/XXX/openssl-native/3.0.1-r0/recipe-sysroot-native/usr/lib/perl5/5.34.0/x86_64-linux/auto/POSIX/POSIX.so' for module POSIX:
| XXX/buildtools-extended-tarball/1.0-r0/testimage-sdk/sysroots-uninative/x86_64-linux/lib/libm.so.6: version `GLIBC_2.35' not found
| (required by XXX/buildtools-extended-tarball/1.0-r0/testimage-sdk/XXX/openssl-native/3.0.1-r0/recipe-sysroot-native/usr/lib/perl5/5.34.0/x86_64-linux/auto/POSIX/POSIX.so) at
| XXX/buildtools-extended-tarball/1.0-r0/testimage-sdk/XXX/openssl-native/3.0.1-r0/recipe-sysroot-native/usr/lib/perl5/5.34.0/XSLoader.pm line 111.
| at XXX/buildtools-extended-tarball/1.0-r0/testimage-sdk/XXX/openssl-native/3.0.1-r0/recipe-sysroot-native/usr/lib/perl5/5.34.0/x86_64-linux/POSIX.pm line 24.
which clearly shows the glibc symbol issue.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
DEPRECATED_CRYPTO_FLAGS ?= ""
do_configure () {
+ # When we upgrade glibc but not uninative we see obtuse failures in openssl. Make
+ # the issue really clear that perl isn't functional due to symbol mismatch issues.
+ cat <<- EOF > ${WORKDIR}/perltest
+ #!/usr/bin/env perl
+ use POSIX;
+ EOF
+ chmod a+x ${WORKDIR}/perltest
+ ${WORKDIR}/perltest
+
os=${HOST_OS}
case $os in
linux-gnueabi |\