When running bat via the releases bat-v0.2.0-x86_64-unknown-linux-gnu.tar.gz , it complains about a missing shared library:
_error while loading shared libraries: libcurl-gnutls.so.4: cannot open shared object file: No such file or directory_
There is no libcurl-gnutls in CentOS per https://www.centos.org/forums/viewtopic.php?t=64227
Thank you for reporting this. I have switched to using libcurl4-openssl in #32. I hope this will fix this problem.
Could you please test if this has been resolved in 0.2.1?
the message is different now!
error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
It seems it is/was a problem also with servo
https://github.com/servo/servo/issues/12015
as https://github.com/servo/servo/issues/12015#issuecomment-376802387 indicates, the version of SSL required is quite old. Would it be possible for you to bump up the version?
The oldest version I can find is 1.0.2.
Thank you for investigating. We might actually even be able to drop the ssl dependency completely (it's currently required by libgit2, but it can be configured not to use ssl - and we don't need any features that would require ssl). I will look into it.
Released as v0.2.2. Would love to get some feedback if it worked this time :smiley:
It works on Fedora 26 (glibc is 2.25)
On CentOS 7.4.1708 there is a GLIBC version problem
/lib64/libc.so.6: version `GLIBC_2.18' not found (required by ./bat)
yum list glibc shows that latest version is 2.17
It seems Centos 7.5 will also have 2.17.
It works on Fedora 26 (glibc is 2.25)
Great, thank you for checking.
On CentOS 7.4.1708 there is a GLIBC version problem
/lib64/libc.so.6: version `GLIBC_2.18' not found (required by ./bat)
Could you please open a new ticket to track this? This is unrelated to the ssl issue in this ticket. Thank you!
error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
I had the same issue, fixed now in Fedora 28. Thanks
Most helpful comment
I had the same issue, fixed now in Fedora 28. Thanks