🚀 Continue to support GLIBC_2.28 in binary release

[David-Else]

0.11.3 worked fine on RHEL8/Centos8/RockyLinux8, but now delta-0.12.1-x86_64-unknown-linux-gnu.tar.gz gives:

delta: /lib64/libc.so.6: version `GLIBC_2.29' not found (required by delta)

Maybe another binary might work? I am not sure what all the extensions mean.

Can you please keep on supporting GLIBC_2.28? Thanks!

[phil-blain]

I confirm (on RHEL 8.3).

[David-Else]

unknown-linux-musl.tar.gz works OK.

[phil-blain]

Thanks for the workaround ! I wouldn't have thought of trying a musl-compiled binary on a glibc system. It does work though, since the delta binary in the -musl tarball is a static executable.

[dandavison]

Hi all, I do not have particular expertise in this area. I believe that delta binaries are being built using procedures that are standard for Rust projects building via GitHub actions, so I don't think there are delta bugs in this area. However, I am open to advice / suggestions here and it's of course possible that something can be improved in the delta build config: https://github.com/dandavison/delta/blob/master/.github/workflows/cd.yml

[dandavison]

One strategy for investigating that comes to mind would be, if you come across a delta binary that is problematic, one could check a Rust+GitHubActions project such as bat or ripgrep to see whether they build a binary for the same architecture/libc, and see whether the same problem occurs with their binary.

[phil-blain]

I googled a bit and it seems it is requiring the glibc version of the system where it's compiled. One alternative is to build in a Docker container (like the offical Rust ones).

[phil-blain]

In fact looking at https://github.com/sharkdp/bat/pull/2194 it seems it is only a matter of setting use-cross=true also for x86_64-unknown-linux-gnu :)