Re: [OE-core] [PATCH] openssl10: remove extra slash from libdir path
On Fri, Sep 21, 2018 at 04:41:50PM +, Peter Kjellerstedt wrote:
> > diff --git a/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
> > b/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
> > index b7297fc..f09782c 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="$( basename "${libdir}" )"
>
> You are making assumptions about the value of ${libdir} here.
> May I suggest the following instead (just in case someone has
> defined libdir as ${prefix}/foo/lib):
>
> libdirleaf="$(echo ${libdir} | sed s:^$useprefix/*::)"
Ok, sending v2 with this.
-Mikko
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] openssl10: remove extra slash from libdir path
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org core-boun...@lists.openembedded.org> On Behalf Of Mikko Rapeli
> Sent: den 21 september 2018 18:02
> To: openembedded-core@lists.openembedded.org
> Cc: Michael Ho ; Thomas Witt
> Subject: [OE-core] [PATCH] 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
> Cc: Thomas Witt
> Cc: Michael Ho
> Cc: Ross Burton
> ---
> meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
> b/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
> index b7297fc..f09782c 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="$( basename "${libdir}" )"
You are making assumptions about the value of ${libdir} here.
May I suggest the following instead (just in case someone has
defined libdir as ${prefix}/foo/lib):
libdirleaf="$(echo ${libdir} | sed s:^$useprefix/*::)"
> perl ./Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} shared
> --prefix=$useprefix --openssldir=${libdir}/ssl --libdir=$libdirleaf $target
> }
>
> --
> 1.9.1
//Peter
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] 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
Cc: Thomas Witt
Cc: Michael Ho
Cc: Ross Burton
---
meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
b/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
index b7297fc..f09782c 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="$( basename "${libdir}" )"
perl ./Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} shared
--prefix=$useprefix --openssldir=${libdir}/ssl --libdir=$libdirleaf $target
}
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
