On Apr 6, 2018, at 7:20 AM, Tim Chase wrote:
>
> $ ~/bin/fossil
> fossil: error while loading shared libraries: libssl.so.1.1:
> cannot open shared object file: No such file or directory
Given how frequently new security flaws are found in OpenSSL, I think it’s
probably for the best that this one remain dynamically-linked. Also, it’s
pretty commonly available everywhere.
> I do have some libssl.so on the hosted box in question
>
> $ find /usr -name libssl.so\* 2>/dev/null
> /usr/lib64/libssl.so.10
> /usr/lib64/libssl.so.1.0.1e
> /usr/lib64/libssl.so
Right, so the problem is simply that the binary you’re running was built on a
different host platform than the one you’re actually trying to run the binary
on.
If I were you, I’d build my own Fossil binary on a more similar system, so that
it *dynamically* linked to OpenSSL 1.0 rather than to 1.1.
That emphasis is because you want package upgrades to give you new OpenSSL
fixes ASAP without requiring that you remember to — or even realize that you
need to — relink your Fossil binary to a static OpenSSL library.
> Begging and pleading for the hosting service
> in question to install fossil from their repos is likely out of the
> question because they're pretty horrible and I'm mostly moving stuff
> off them.
Not to mention that you say this is a Debian box, and Debian is still shipping
Fossil 1.37, which probably isn’t what you want to be running now.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users