I can only think of patching openssl to pick up a oe-specific
environment variable pointing to staging_libdir_native - making a
wrapper for every native binary that sets those variables doesn't seem
feasible.
Alex
On Wed, 14 Sept 2022 at 10:09, Mikko Rapeli <mikko.rap...@linaro.org> wrote:
>
> Hi,
>
> Found the root cause. As suggested on #pyco too maybe native openssl
> was mising legacy support.
> It wasn't but loading the on purpose hidden openssl legacy.so was
> failing. It is located in
> recipe-sysroot-native/usr/lib/ossl-modules/legacy.so and only found
> via OPENSSL_MODULES
> variable which wasn't set for python3-native users. These custom
> variables are set in the native openssl
> wrapper script and this also fixes the not found openssl.cnf. Now I
> could send a patch which sets
> the OPENSSL_CONF, OPENSSL_ENGINES and OPENSSL_MODULES paths for python3
> users via python3native.bbclass:
>
> --- a/meta/classes-recipe/python3native.bbclass
> +++ b/meta/classes-recipe/python3native.bbclass
> @@ -28,3 +28,10 @@ export PYTHONNOUSERSITE = "1"
>
> # autoconf macros will use their internal default preference otherwise
> export PYTHON
> +
> +# find openssl under python, see openssl native wrapper
> +export OPENSSL_CONF="${STAGING_LIBDIR_NATIVE}/ssl-3/openssl.cnf"
> +export SSL_CERT_DIR="${STAGING_LIBDIR_NATIVE}/ssl-3/certs"
> +export SSL_CERT_FILE="${STAGING_LIBDIR_NATIVE}/ssl-3/cert.pem"
> +export OPENSSL_ENGINES="${STAGING_LIBDIR_NATIVE}/engines-3"
> +export OPENSSL_MODULES="${STAGING_LIBDIR_NATIVE}/ossl-modules"
>
> but that is still a copy of those variables which openssl recipe owns,
> and other users of openssl may
> have similar issues. Is there a way to export these for everyone who
> depends directly or indirectly
> from openssl-native?
>
> Cheers,
>
> -Mikko
>
> On Tue, 13 Sept 2022 at 15:24, Richard Purdie
> <richard.pur...@linuxfoundation.org> wrote:
> >
> > On Tue, 2022-09-13 at 14:13 +0300, Mikko Rapeli wrote:
> > > On Tue, 13 Sept 2022 at 13:34, Richard Purdie
> > > <richard.pur...@linuxfoundation.org> wrote:
> > > > Are you using uninative? I'd have expected glibc and pthreads to come
> > > > from there rather than the host.
> > >
> > > Yes, using uninative, not host libc, sorry. Added full list of
> > > openat()'d files to the end of this email, from master branch with
> > > this patch applied.
> > > Delta to without this patch is just a few python modules. I can't see
> > > anything wrong in that list.
> >
> > It looks correct to me too.
> >
> > It is weird it is ubuntu 18.04 as we had a lot of problems with the
> > rust SDK work specifically on that platform. The problem there was rust
> > running things with LD_LIBRARY_PATH set which meant host tools tried to
> > use the SDK sysroot libs which then broke in interesting ways. It was
> > specific to the form of the version mismatch on 18.04.
> >
> > I have no idea if there is a connection, your strace output certainly
> > suggests not.
> > >
> > > > > And then in bitbake -c devshell busybox:
> > > > >
> > > > > # python3 -c "from OpenSSL import crypto"
> > > > >
> > > > > I guess there is no way to add a test like that for
> > > > > python3-cryptography-native?
> > > >
> > > > You could probably put that in do_configure to test it?
> > >
> > > Yes, on my layer and recipes I can do this. But I'd rather upstream
> > > the test to python3-cryprography-native or somewhere else but I guess
> > > native recipes don't have selftests or similar.
> >
> > I was wondering about putting something into upstream recipe...
> >
> > We do somehow need to get more information about what is breaking here
> > :/.
> >
> > Cheers,
> >
> > Richard
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170642):
https://lists.openembedded.org/g/openembedded-core/message/170642
Mute This Topic: https://lists.openembedded.org/mt/93651845/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
