summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorMikko Rapeli <mikko.rapeli@bmw.de>2018-09-24 11:07:33 +0300
committerRichard Purdie <richard.purdie@linuxfoundation.org>2018-09-25 23:15:42 +0100
commitd286e91bbdcecef16153313fe5e1e0e0cb469612 (patch)
tree40e6abe60cebdfd46079c404c058b44683eb052c
parent547e81b678a616ebbdf2e5cc86e918966fafb894 (diff)
downloadopenembedded-core-contrib-d286e91bbdcecef16153313fe5e1e0e0cb469612.tar.gz
openembedded-core-contrib-d286e91bbdcecef16153313fe5e1e0e0cb469612.tar.bz2
openembedded-core-contrib-d286e91bbdcecef16153313fe5e1e0e0cb469612.zip
openssl10: remove extra slash from libdir path
The configure script ended up creating Makefile with LIBDIR=/lib which got leaked into various places including all pkg-config .pc files where lines like (note the double slash //): libdir=${exec_prefix}//lib ... Libs: -L${libdir} -lcrypto which causes pkg-config --libs to include the full absolute path to the recipe specific sysroot. This isn't a big problem until something like CMake projects start generating their own .cmake modules using this absolute path and exposing them to sysroots of other bitbake recipes thus escaping their recipe specific sysroots. Then the fun begins when these users of the .cmake module start to randomly fail builds with error messages like: /home/builder/src/base/build/tmp/work/corei7-64-linux/package/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-linux/../../libexec/x86_64-linux/gcc/x86_64-linux/7.3.0/ld: cannot find /lib/libpthread.so.0 /home/builder/src/base/build/tmp/work/corei7-64-linux/package/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-linux/../../libexec/x86_64-linux/gcc/x86_64-linux/7.3.0/ld: cannot find /usr/lib/libpthread_nonshared.a collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. WARNING: exit code 1 from a shell command. As luck has it, this problem goes away by recompiling the recipes alone but repeats with multiple recipes here and there when full images are build. A careful inspection of multi page linker command lines shows that some linker paramaters point to libraries in a different recipes sysroot than what bitbake was building when the task failed. So, fix is to remove this one extra slash from openssl library path configuration option. This changes openssl Makefile to have: LIBDIR=lib and all users of LIBDIR variable in the Makefile are already adding slashes as path separators if that is needed. With this the generated .pc files have: libdir=${exec_prefix}/lib and pkg-config --libs knows to strip the already default sysroot path away. This then fixes the generated .cmake files to not include these absolute paths and fixes the random build failures when building images. Thanks to Thomas, Michael and Ross for debugging support! Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de> Cc: Thomas Witt <thomas.witt@bmw.de> Cc: Michael Ho <michael.ho@bmw.de> Cc: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-rw-r--r--meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb2
1 files changed, 1 insertions, 1 deletions
diff --git a/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb b/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
index 84e086c2f6..766110958e 100644
--- a/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
+++ b/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
@@ -191,7 +191,7 @@ do_configure () {
if [ "x$useprefix" = "x" ]; then
useprefix=/
fi
- libdirleaf="$(echo ${libdir} | sed s:$useprefix::)"
+ libdirleaf="$( echo "${libdir}" | sed "s:^$useprefix/*::" )"
perl ./Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} shared --prefix=$useprefix --openssldir=${libdir}/ssl --libdir=$libdirleaf $target
}