Hacker News Reader

Comment by dataflow | Hacker News Reader

Tried it, didn't work.

Arch:

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

Ubuntu:

  $ ./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

View on HN

The docs explain that internally ~/.exodus/bin/git is actually a shell wrapper that calls ~/.exodus/bin/git-x (which itself might be a symlink). The -x suffix is added by exodus.

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 anything that relies on the name of the executing file will break.

Git is extended by adding `git-$commandname` executables to $PATH. So `git-x` would extend git with a new command called `x`, i.e. `git x`.

“If you ever try to relocate a binary that doesn't work with the default configuration, the --detect option is a good first thing to try.”

From the README file…

I get literally the same error with --detect. And honestly when the README says "transferring a piece of software that's working on one computer to another is as simple as this" you can't blame me for taking that at face value.

I'm the author and I agree that you're correct in assuming that what you ran should work. I just tested this with git on arch and I was able to reproduce the issue. I'll look into why this is happening and hopefully push up a fix soon, but I also invite you to try it out with another binary in the meantime. There seems to be something particular about git, and I think you'll have better luck trying it with almost any other ELF binary.

My guess is that it’s due to git looking at its own base name to figure out which command it’s supposed to run as, kind of like busybox does.

Yep. Source of that error message. https://github.com/git/git/blob/master/git.c#L879

Fun anecdote about that: at work we added a wrapper around nvcc to point it at the right compiler, and renamed the original "nvcc" binary to ".nvcc-wrapped". But nvcc looks at argv[0] to print out its name in the --version output, and it truncates anything after a period (presumably to handle things like "nvcc.exe"?). And CMake's CUDA detection looks at nvcc --version. So CMake went down a really weird path where it knew that nvcc existed but didn't really believe it was nvcc, which was extremely confusing until I looked at some log output and went "wait, why isn't nvcc printing its own name".

Oh hi, thanks for replying! So funny enough, git was literally the first thing I tried, because it was easily the first thing I could think of where being able to move later versions of it to earlier versions of Linux would've made my life easier. I'm not sure if anything else really falls in this category for me. But on your suggestion, I just tried Python 3.9, clang++, and g++, and didn't get errors for any of them. It's pretty nifty! Thanks for writing it.

clang++ also is just a symlink to clang, and clang uses the filename to change the language mode to c++.

So why does that work?

clang just checks if the name starts with clang++ probably.

I checked this, the logic is as follows. The following suffixes are mapped to the equivalent driver flags:

    {"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"}

`clang++-x` matches none of these. Then the same logic is applied to the name with any of "0123456789." trimmed from the right. Still no match. Then the trailing `-component` is stripped, and `clang++` matches.

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.

> 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++`.

See my comment in the parent thread but basically Git commands like ‘git thing’ actually dispatch to lower level commands, usually with the name git-thing (I’m not a git expert, just something I’ve noticed). And it seems that git builtins are dispatched into by calling the git binary with a different basename, and this conflicts with your convention of adding -x to binary names.

Is having the -x necessary in filenames, or could you add a subdirectory and use the same original file name for a bundled file?

Reply on news.ycombinator.com