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 (#170640):
https://lists.openembedded.org/g/openembedded-core/message/170640
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]
-=-=-=-=-=-=-=-=-=-=-=-
