Release binary fails mysteriously.

[RAOF]

I've downloaded the release tarball from here, extracted it into ~/.local/bin (which is in $PATH) and then tried to run it on an Ubuntu 18.10 (Cosmic Cuttlefish) development system.

It fails in an extremely odd way.

> ~/.local/bin/art --help
zsh: no such file or directory: /home/chris/.local/bin/art

Huh.

 > ldd ~/.local/bin/art 
	linux-vdso.so.1 (0x00007ffe0bdd3000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb17762f000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb177625000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb177604000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb1775ea000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb177400000)
	/nix/store/2kcrj1ksd2a14bm5sky182fv2xwfhfap-glibc-2.26-131/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fb1793bb000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb177273000)

Hm, maybe the oddly stored location for ld-linux is confusing it?

>  /lib64/ld-linux-x86-64.so.2 ~/.local/bin/art  
thread 'main' panicked at 'not yet implemented: sub: ', src/lib.rs:83:21
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Huh! Well, that at least loads. I wonder what the backtrace is?

> RUST_BACKTRACE=1 /lib64/ld-linux-x86-64.so.2 ~/.local/bin/art 
thread 'main' panicked at 'not yet implemented: sub: ', src/lib.rs:83:21
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: __libc_start_main
  15: <unknown>

Heh. Not very enlightening!

Other rust projects (notably, my own, cargo, and ripgrep) build and work fine on this system; I wonder what's odd with the art binary?

[dpc]

@RAOF Hello fellow Nix user!

I've just tried downloading https://github.com/vitiral/artifact/releases/download/2.0.0/artifact-2.0.0-x86_64-unknown-linux-gnu.tar.gz (from https://github.com/vitiral/artifact/releases) and it just works when dropped into $PATH.

Can you try strace -fff art --help and paste somewhere?

[dpc]

Your original download link doesn't work anymore (expired), so it's different from what I've downloaded.

[dpc]

Oh. Wait. You're not a NixOS user. It's the release binary that was built using NixOS! :D

It just so happens that you have nix installed locally and ldd is able to use it too.

[dpc]

It looks to me that ldd is able to find the right linker, but zsh does not.

What you get when doing /lib64/ld-linux-x86-64.so.2 ~/.local/bin/art is normal.

Here:

> art
thread 'main' panicked at 'not yet implemented: sub: ', src/lib.rs:83:21
note: Run with `RUST_BACKTRACE=1` for a backtrace.

it's just art not handling lack of arguments well.

[RAOF]

Aha! Passing an actual argument results in activity!

I do not, in fact, have nix installed locally; It's not clear to me why ldd can resolve the dynamic loader while binfmt cannot; plausibly it has a more sophisticated lookup mechanism.

I'm somewhat surprised this build works at all on non-nix systems, but I cannot be the first to have tried‽

[dpc]

You could try using patchelf to fix that path: https://nixos.org/patchelf.html

[vitiral]

Hey, sorry I've been AWOL. I think I should be able to address this this week.

[vitiral]

This should be fixed in release 2.0.1. Let me know any more issues!

[dpc]

@vitiral You're back! Great.

[vitiral]

thanks! Still going to be on hiatus for a bit more, but starting to get back into things slowly.