5 ms·

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 is

by 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.

by foob 5y ago

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.