Thank you so much for it!

It just works most of the time, which is wild given how diverse the environments it operates in can be. One piece of software I have struggled with however is w3m.

   Wrong __data_start/_end pair
   Aborted (core dumped)

In the past what I've done when I have to copy a binary somewhere, is statically compile it in a Docker container and export the install files, then copy those over. I have about a half dozen tools prepped like that (gdb, curl, strace, busybox, etc)

You can actually pipe the output of strace into exodus and it will include the files that were accessed by the program in the bundle. For example:

    strace -f nmap --script default 127.0.0.1 2>&1 | exodus nmap

I don't understand what the complaint or expectation is here.

For "simple" bionic libc calls, an LD_PRELOAD shim might be enough for many binaries, though. You'd need to translate all the bionic libc calls to your system's libc calls, but that might just be easier than it seems because the level of compatibility between the two. Bionic is actually a subset of POSIX libc, so you should be able to map all calls to your normal system calls.

I don't know how well-maintained the project is, but https://github.com/Cloudef/android2gnulinux might just do the trick for you.

Instead, what I think (hope) will happen is a simultaneous increase in prevalence of two things: "effectively static" software releases (whether that's an actual static binary or a container/flatpak/exodus-bundled folder/whatever), and sandboxing/isolation tools at the OS level, to prevent the statically linked dependencies in installed programs from causing harm to the system.

There will probably always be exceptions made for software that by necessity must be integrated tightly with the whole computer (window managers etc.), but I don't think people are going to rediscover dynamic linking en masse.

The cool thing would be multi-host static binaries i.e. binaries that host multiple "apps" and its dependencies and use commandline option to launch specific "app" from the binary(or without commandline option, provide a app list from which the user can select that app to run)

My first thought was someone is thinking about something like:

https://ahgamut.github.io/c/2021/02/27/ape-cosmo/

There is also something similar that can make binaries that run even bare metal or as EFI apps. But I can't find at the moment. (Maybe someone else has the link?)

Or add a binary launcher in front of a squashfs image of a live distro?

Something like that could be done with AppImage I guess.

    # Create a.out <- one/libx.so <- one/sub/liby.so
    $ echo 'int g(){return 42;}' | gcc -shared -o one/sub/liby.so -x c -
    $ echo 'extern int g(); int f(){return g();}' | gcc -shared -o one/libx.so -x c - -Lone/sub -ly '-Wl,-rpath,$ORIGIN/sub'
    $ echo 'extern int f(); int main(){return f();}' | gcc -x c - -Lone -lx '-Wl,-rpath,$ORIGIN/one'

    # works fine
    $ ./a.out
    $ echo $?
    42

    # can't locate library through rpath with --inhibit-rpath
    $ /lib64/ld-linux-x86-64.so.2 --inhibit-rpath '' ./a.out
    ./a.out: error while loading shared libraries: libx.so: cannot open shared object file: No such file or directory

    # *does* locate liby.so through rpath!
    $ /lib64/ld-linux-x86-64.so.2 --inhibit-rpath '' --library-path ./a.out
    $ echo $?
    42

Arch:

  $ exodus /usr/bin/git > ./foo

  $ ./foo
  Installing executable bundle in "${HOME}/.exodus"...
  Successfully installed, be sure to add ${HOME}/.exodus/bin to your $PATH.
  $ ~/.exodus/bin/git --version
  fatal: cannot handle x as a builtin

My guess is that git is parsing argv[0] to try and determine which porcelain command to launch and gets very confused by the -x because it is not a git builtin command.

So why does that work?

    {"clang", nullptr}
    {"clang++", "--driver-mode=g++"}
    {"clang-c++", "--driver-mode=g++"}
    {"clang-cc", nullptr}
    {"clang-cpp", "--driver-mode=cpp"}
    {"clang-g++", "--driver-mode=g++"}
    {"clang-gcc", nullptr}
    {"clang-cl", "--driver-mode=cl"}
    {"cc", nullptr}
    {"cpp", "--driver-mode=cpp"}
    {"cl", "--driver-mode=cl"}
    {"++", "--driver-mode=g++"}
    {"flang", "--driver-mode=flang"}

It works by chance...

See https://github.com/llvm/llvm-project/blob/c22b110612600b0d0a... and https://github.com/llvm/llvm-project/blob/c22b110612600b0d0a...

TIL: if you symlink ++ -> clang it works as a compiler in C++ mode.

Note that this is only about the compiler driver mode, i.e. the default libraries, search paths, include directories, etc. The source language is determined by the file extension unless specified with e.g. `-x c++`.

This tools seems easier to use. But the high level result seems quite similar.

Would it maybe even make sense to integrate both tools? I think AppImage is compressed so has an advantage in that point.

Haven’t tested it myself yet but always wanted to

I still

apt update; apt upgrade

And look for config in /etc

Linux is a community, sharing space is important to me.

Docker also will have a much bigger overhead since you basically need to include a whole distro instead of just a few libraries. And I particularly find Docker applications to be sufficient slow to start that I never want to use CLI tools via Docker.