Re: py313-tortoisehg-7.2.2 on NetBSD 11.0; mysterious segfault

Rhialto <[email protected]> Mon, 17 Aug 2026 18:07:03 +0200
Newsgroups	gmane.os.netbsd.general
Message-ID	<[email protected]>
On Mon 17 Aug 2026 at 09:16:32 -0400, Greg Troxel wrote:
> Please follow up on list and explain your finding.  It's pointing out
> that you are off the rails of pkgsrc and having a "NetBSD binary compat
> is not as good as it should be" problem.

My suspicion is that somewehere in the stack of tortoise-hg, something
is doing the equivalent of  dlopen("libcrypto.so")  instead of
dlopen("libcrypto.so.15"). However I have not been able to pinpoint
where this would be:

These are all occurrences of "libcrypto.so" in /usr/pkg/lib/python3.13:

- /usr/pkg/lib/python3.13/lib-dynload/_ssl.so: -lcrypto.15 =>
  /usr/lib/libcrypto.so.15

- /usr/pkg/lib/python3.13/lib-dynload/_hashlib.so: -lcrypto.15 =>
  /usr/lib/libcrypto.so.15

- /usr/pkg/lib/python3.13//site-packages/cryptography/hazmat/bindings/_rust.abi3.so:
  -lcrypto.15

/usr/pkg/bin/python3.13 itself does not link to libcrypto, so it must be
some indirect linking or some dlopen().

/usr/pkg/lib/python3.13/site-packages/OpenSSL seems to use ffi to access
libcrypto, and ffi seems to use dlopen(). But I don't see py313-OpenSSL
in the dependency tree ("make show-depends-recursive").

> You also might check if whatever python library that loads libcrypto is
> loading something else that now is linked to version 16, or if you
> somehow installed a binary pacakge via pkgin.

I'm still searching what pulls in libcrypto; I am certain I have
installed nothing via pkgin since I always build my packages locally in
a sandbox.

> Then, update all your packages to a version built on 11 (there's no joy
> in relying on binary compat long term).[q

I think this is the first time I run into an issue like this. NetBSD's
binary compat with the previous version is pretty good. So far I tended
to do a full package rebuild on the next quarterly branch after a NetBSD
upgrade and that works fine for most practical purposes.

And the workaround I found looks pretty acceptable. I see a minor
disadvantage: if thg spawns subcommands, they also get libcrypto forced
into them, even if not needed. Probbaly something can be done with an
LD_LIBRARY_PATH that first points to a special directory which only has
(links to) the desired version of libcrypto only.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert                            <rhialto/at/falu.nl>
\X/ There is no AI. There is just someone else's work.           --I. Rose
signature.asc (application/pgp-signature, 525 B)