summaryrefslogtreecommitdiffstats
path: root/meta/recipes-connectivity
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:49 +0100
commit1d9295820d323d025e94b5cca4beaf30469ead5c (patch)
tree69382d572055cf6d1dad7208afbca7d8dd9f0d49 /meta/recipes-connectivity
parent72cd62e66e2f65876415ed9ac91d899d22ed7ddc (diff)
downloadpoky-1d9295820d323d025e94b5cca4beaf30469ead5c.tar.gz
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! (From OE-Core rev: d286e91bbdcecef16153313fe5e1e0e0cb469612) 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>
Diffstat (limited to 'meta/recipes-connectivity')
-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 () {
191 if [ "x$useprefix" = "x" ]; then 191 if [ "x$useprefix" = "x" ]; then
192 useprefix=/ 192 useprefix=/
193 fi 193 fi
194 libdirleaf="$(echo ${libdir} | sed s:$useprefix::)" 194 libdirleaf="$( echo "${libdir}" | sed "s:^$useprefix/*::" )"
195 perl ./Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} shared --prefix=$useprefix --openssldir=${libdir}/ssl --libdir=$libdirleaf $target 195 perl ./Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} shared --prefix=$useprefix --openssldir=${libdir}/ssl --libdir=$libdirleaf $target
196} 196}
197 197