5 ms·

Tried it, didn't work. Arch: $ exodus /usr/bin/git > ./foo Ubuntu: $ ./foo Installing executable bundle in "${HOME}/.exodus"... Successfully install

• wffurr 5y ago
  “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…
  • dataflow 5y ago
    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.
    • foob 5y ago
      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.
      • elteto 5y ago
        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.
      • henrydark 5y ago
        Is having the -x necessary in filenames, or could you add a subdirectory and use the same original file name for a bundled file?
      • staticfloat 5y ago
        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.
        • tomjakubowski 5y ago
          Yep. Source of that error message. https://github.com/git/git/blob/master/git.c#L879 https://github.com/git/git/blob/master/git.c#L879
        • geofft 5y ago
          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".
      • dataflow 5y ago
        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.
        • stabbles 5y ago
          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?
          • pseudalopex 5y ago
            clang just checks if the name starts with clang++ probably.
            • stabbles 5y ago
              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/c22b110612600b0d0a8003f40b1cf6e37c4696c2/clang/lib/Driver/ToolChain.cpp#L135-L163 https://github.com/llvm/llvm-project/blob/c22b110612600b0d0a... and https://github.com/llvm/llvm-project/blob/c22b110612600b0d0a8003f40b1cf6e37c4696c2/clang/lib/Driver/ToolChain.cpp#L177-L201 https://github.com/llvm/llvm-project/blob/c22b110612600b0d0a... TIL: if you symlink ++ -> clang it works as a compiler in C++ mode.
• elteto 5y ago
  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.
  • deleted 5y ago
    [deleted]
  • unbanned 5y ago
    So anything that relies on the name of the executing file will break.
  • ljm 5y ago
    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`.