Bug 688524 – net-misc/curl-7.65.1 with dev-libs/libressl-2.9.2 fails execution looking for libssl.so.46 and libcrypto.so.44 while libssl.so.47 and libcrypto.so.45 are provided

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Mattia Rossi 2019-06-23 02:57:44 UTC]

Premise:

libressl-2.9.2 is installed which provides libssl.so.47 and libcrypto.so.45
glibc has been rebuild
env-update executed
amd64 17.1 no-multilib profile in use with all migration steps performed, meaning the system has been rebuild (emerge -e) until it failed building cmake which relies on curl (see below)

Problem:

curl-7.65.1 fails to execute as it's looking for libssl.so.46 and libcrypto.so.44 after being successfully built with those files not even on the system.

Because of that cmake fails to build and git fails to pull half of the time, when using curl as backend

I can create symlinks from libssl.so.47 to libssl.so.46 and from libcrypto.so.45 to libcrypto.so.44 which fixes everything - but probably just until some call at some point will cause a segfault... not looking forward to that, so not the right solution IMHO.

[Comment 1 Mattia Rossi 2019-07-09 07:20:43 UTC]

SOLVED

So, turns out this problem is a mix of circular dependencies and me not paying attention:

a) openssh does not install nor require libssh
b) curl uses libssh
c) cmake requires curl to build and install
d) libssh requires cmake to build and install

libssh was outdated and pointing to the old libssl.so.46 and libcrypto.so.44, thus making curl fail execution, thus making cmake fail the build, thus never getting to the update of libssh which requires cmake.

I had a hunch that it could be ssh, but rebuilding openssh again and again didn't solve the problem, so I didn't understand. duh.

Solution: 
- create a symlink from libssl.so.47 to libssl.so.46 and from libcrypto.so.45 to libcrypto.so.44
- build cmake (as curl would work for the time being), 
- delete the symlinks (for safety reasons)
- rebuild libssh

all good