I was debugging this: ``` $ cargo check cargo: error while loading shared libraries: libssh2.so.1: cannot open shared object file: No such file or directory $ ``` And was pretty confused how this could happen. Turns out: ``` $ rpm -q --whatprovides 'libssh2.so.1()(64bit)' julia-1.11.0-8.beta1.fc40.x86_64 ``` Which is definitely wrong. It looks like there's a bunch of vendored .so libraries built into `/usr/lib64/julia`. (Are you *sure* all of those need to be vendored?) Now there's definitely an rpm mis-feature here where it happily adds Provides for things not actually in the public linker paths. Here's a bit where we fixed a similar thing in rpm-ostree long ago: https://src.fedoraproject.org/rpms/rpm-ostree/c/db3835a322daa5a0cb352ed3264b114d29d5cda6?branch=rawhide (Although since then we switched to statically linking which avoids this entirely) Reproducible: Always
Julia seems to bundle a *lot* of things. The fact that these commits are only on the f40 branch but not on the rawhide branch is also kind of suspicious. https://src.fedoraproject.org/rpms/julia/blob/f40/f/sources Looking at the Provides from the build that has been unpushed from f40-testing by now, this is definitely not handled correctly. As built from the tip of the f40 branch, julia provided shared libraries for - libcurl.so.4 - libgmp.so.10 - libgmpxx.so.4 - libmbedcrypto.so.7 - libmbedtls.so.14 - libmbedx509.so.1 - libssh2.so.1 All of these Provides MUST be filtered out. (And whether it's a good idea to bundle crypto libraries is a good idea at all is a separate topic.)
*** This bug has been marked as a duplicate of bug 2274270 ***