Hacker News Reader

Comment by foob | Hacker News Reader

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.

View on HN

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

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

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