The binary doesn't like other linux distro

[mio-19]

I assume that it is built on Ubuntu and only work on Ubuntu or similar distros.
I am on Archlinux. I installed llvm17 from aur. My llvm17 is in /usr/lib/llvm17/ so I created symlinks

sudo ln -s /usr/lib/llvm17/ /usr/lib/llvm-17

$ ./sn-bindgen-x86_64-pc-linux
./sn-bindgen-x86_64-pc-linux: error while loading shared libraries: libclang-17.so.17: cannot open shared object file: No such file or directory

I saw this so I created symlink from /usr/lib/llvm-17/lib/libclang.so.17 to /usr/lib/llvm-17/lib/libclang-17.so.17

sudo ln -s /usr/lib/llvm-17/lib/libclang.so.17 /usr/lib/llvm-17/lib/libclang-17.so.17

$ ./sn-bindgen-x86_64-pc-linux
./sn-bindgen-x86_64-pc-linux: error while loading shared libraries: libclang-17.so.17: cannot open shared object file: No such file or directory

Finally I successfully run the binary with LD_LIBRARY_PATH

$ LD_LIBRARY_PATH=/usr/lib/llvm-17/lib/ ./sn-bindgen-x86_64-pc-linux
Missing expected flag --package!
Missing expected flag --header!

Usage: bindgen --package <string> --header <string> [--scala] [--c] [--link-name <string>] [--c-import <string>]... [--clang-include <string>]... [--clang <string>]... [--quiet] [--trace | --info | --warning | --error] [--llvm-bin <string> | --clang-path <string> | --no-system] [--render.no-constructor <string>] [--render.opaque-structs <string>] [--render.no-comments] [--render.no-location] [--render.external-path <string>]... [--render.external-name <string>]... [--out <string>] [--multi-file] [--export] [--exclude-system-path <string>]... [--flavour <string>]

[keynmol]

That is unfortunatey but I guess expected.

The true fix would be to provide a statically linked binary: #13 but the process itself has a lot of moving parts and I haven't even started yet.

In the interim, I'm not familiar at all with how binaries are distributed for various linux distros without having to provide lots of os-specific binaries. If you have any resources to link on how other people do it, I will consider doing the work to make it more portable.

I guess one can attempt to modify the rpath (or lpath?) of the binary after it's already built to provide more fallback options..