Binaries built by Github are not working

[drupol]

Hi,

I'm trying to use a binary made by Github on my Linux laptop and I have this issue:

$ ./dura                                                                                                                                                                                                                         
Failed to execute process './dura'. Reason:
The file './dura' does not exist or could not be executed.
$ ldd dura                                                                                                                                                                                                                   
        linux-vdso.so.1 (0x00007ffd1d5bd000)
        libssl.so.1.1 => not found
        libcrypto.so.1.1 => not found
        libz.so.1 => not found
        libgcc_s.so.1 => /nix/store/s9qbqh7gzacs7h68b2jfmn9l6q4jwfjz-glibc-2.33-59/lib/libgcc_s.so.1 (0x00007f75be6f2000)
        libpthread.so.0 => /nix/store/s9qbqh7gzacs7h68b2jfmn9l6q4jwfjz-glibc-2.33-59/lib/libpthread.so.0 (0x00007f75be6d2000)
        libm.so.6 => /nix/store/s9qbqh7gzacs7h68b2jfmn9l6q4jwfjz-glibc-2.33-59/lib/libm.so.6 (0x00007f75be58f000)
        libdl.so.2 => /nix/store/s9qbqh7gzacs7h68b2jfmn9l6q4jwfjz-glibc-2.33-59/lib/libdl.so.2 (0x00007f75be58a000)
        libc.so.6 => /nix/store/s9qbqh7gzacs7h68b2jfmn9l6q4jwfjz-glibc-2.33-59/lib/libc.so.6 (0x00007f75be3c5000)
        /lib64/ld-linux-x86-64.so.2 => /nix/store/s9qbqh7gzacs7h68b2jfmn9l6q4jwfjz-glibc-2.33-59/lib64/ld-linux-x86-64.so.2 (0x00007f75bea64000)

I have the feeling that we should build it statically. I never did that yet in Rust, maybe you guys will know more about that.

[tkellogg]

I don't know much about building Rust yet. I noticed this was a potential problem earlier when you had that error about glibc.

[JakeStanger]

I've been exclusively working on it & building it on Linux (Arch) so I know it does work. I've not had to do anything except cargo build.

You should definitely avoid static linking these days, especially when it comes to NixOS and it's weird filesystem structure. It doesn't really serve any benefit and often results in having to patch code to get it to build on different platforms. Also with Nix you'll more than likely need a derivation to build it locally and ensure everything is there at build-time.

From your ldd it just looks like the package is missing a couple of deps. libssl and libcrypto should both be provided by openssl, and libz from zlib.

Here's mine for comparison:

λ ldd target/debug/dura 
	linux-vdso.so.1 (0x00007ffc2b76d000)
	libgit2.so.1.3 => /usr/lib/libgit2.so.1.3 (0x00007f039df03000)
	libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007f039de71000)
	libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x00007f039db90000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f039db75000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f039db54000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007f039da10000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f039da07000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f039d83b000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f039e90f000)
	libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f039d7c4000)
	libhttp_parser.so.2.9 => /usr/lib/libhttp_parser.so.2.9 (0x00007f039d7b8000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f039d79e000)
	libssh2.so.1 => /usr/lib/libssh2.so.1 (0x00007f039d75d000)

[drupol]

I know all of this, but I wasn't complaining for my specific use case, there might be some other people having the same issue.

In order to foster a greater adoption, I would suggest to provide also a build based on musl, just like fd is doing.

Ideally, we should provide the same amount of versions as this package.

PS: Hence the fact that I'm not reacting to "NixOS and it's weird filesystem structure.", the idea here is to make sure that the shipped software works for every available Linux, with a statically compiled version or not.

[JakeStanger]

PS: Hence the fact that I'm not reacting to "NixOS and it's weird filesystem structure.", the idea here is to make sure that the shipped software works for every available Linux, with a statically compiled version or not.

Oh I'm not suggesting we don't support NixOS or anything like that, I'm just noting it's different.

I don't think static binaries solve any problems, and by the looks of it aren't supported by Rust anyway: https://doc.rust-lang.org/reference/linkage.html

What we should do is update the readme with a list of non-cargo build/runtime deps, and just ensure any distro packages correctly depend on these.

[drupol]

I think we could just solve this by providing a musl version, don't you think?

Or we could "adapt" their Github action file to our needs?

[JakeStanger]

There's certainly no harm in setting up another action to produce a musl build, it sounds pretty easy to do so I'm on board.

Their action file has a step for producing a Debian file. That'd possibly be very useful to have if nothing else to help with #68.