#80527 introduces behavior change that breaks icecream's icecc-create-env script

[13steinj]

Script and some relevant lines for reference: https://github.com/icecc/icecream/blob/d680e4fcb261d7de271ddce331f4a23adbfd573f/client/icecc-create-env.in#L313-L316

#80527 (more accurately combined with the minor commit 0f76d9f on top) results in a behavior change at least when building clang with -DCLANG_CONFIG_FILE_SYSTEM_DIR=/path/to/where/clang/will/be/installed/to/cfg, and supplying the produced default-clang (supplying merely clang is unaffected).

Prior behavior: the script ends up executing the equivalent of

/opt/clang-18.1.8/cfg/default-clang -print-prog-name=default-clang
# output: /opt/clang-18.1.8/cfg/default-clang

New behavior: no full path.

/opt/clang-19.1.1/cfg/default-clang -print-prog-name=default-clang
# output: default-clang

It is unclear if this behavior change to -print-prog-name is intentional hence why I'm filing this issue here first before filing a PR to icecc/icecream.

Resolution/workaround (at least for this execution of -print-prog-name is simple-- I'll just modify the script to call -no-canonical-prefixes -print-prog-name.

/opt/clang-19.1.1/cfg/default-clang -no-canonical-prefixes -print-prog-name=default-clang
# output: /opt/clang-19.1.1/cfg/default-clang

There is another use of -print-prog-name in this script that I appears unaffected as it requests the name of actual binaries (potentially outside of the clang installation directory? is the key factor?) rather than a clang config symlink to one.

[13steinj]

I understand the original intent is

[1] If a user creates a symlink to the regular file clang and uses the
default -canonical-prefixes, they now consistently get search and
library paths relative to the regular file clang, not mix-and-match
paths.

[2] If a user creates a symlink to the regular file clang and replaces
some directorys from the actual installation, they should change the
symlink to a wrapper that calls the underlying clang with
-no-canonical-prefixes.

I assume this actually occurs; however the unclear part to me is if side effect

[3] -print-prog-name of such symlinks was supposed to change with this as well to result in just the name of the symlink itself (considering the documentation is unchanged).

More accurately, the behavior changes from "symlinks to the clang binary treat the basename of the symlink as a valid program name such that the output should be the symlink" to "symlinks to the clang binary act as though one passed an invalid program name that clang doesn't know about and thus the output is the input."

Similarly it is unclear how intended effect [2] interacts with icecc / distcc envs; nor how it interacts with clang configs which, are still symlinks (and not wrappers that call the underlying clang; thought I don't know what "replaces some directories from the actual installation" means in this context).

cc @MaskRay in case they can clear some of this up.

[MaskRay]

Resolution/workaround (at least for this execution of -print-prog-name is simple-- I'll just modify the script to call -no-canonical-prefixes -print-prog-name.

/opt/clang-19.1.1/cfg/default-clang -no-canonical-prefixes -print-prog-name=default-clang
# output: /opt/clang-19.1.1/cfg/default-clang

Specifying -no-canonical-prefixes is a resolution instead of a workaround, since the path components /opt/clang-19.1.1/cfg contain symlinks.

Without -no-canonical-prefixes, basically dirname(realpath("/opt/clang-19.1.1/cfg/default-clang")) will be the first element in ProgramPaths.
If that directory doesn't contain an executable default-clang, clang --print-prog-name=default-clang will print unprefixed default-clang.

Before #80527 , there was some inconsistency due to having both InstalledDir and Dir, but that was unintentional.

---

Note: if default-clang is a shell script that invokes an ELF executable file, please note that special logic llvm::sys::fs::getMainExecutable(Argv0, P) in the default -canonical-prefixes mode.

I feel that icecc should invoke the real executable (or a symlink to an ELF executable) with --print-prog-name= instead of a shell script wrapper.

std::string GetExecutablePath(const char *Argv0, bool CanonicalPrefixes) {
  if (!CanonicalPrefixes) {
    SmallString<128> ExecutablePath(Argv0);
    // Do a PATH lookup if Argv0 isn't a valid path.
    if (!llvm::sys::fs::exists(ExecutablePath))
      if (llvm::ErrorOr<std::string> P =
              llvm::sys::findProgramByName(ExecutablePath))
        ExecutablePath = *P;
    return std::string(ExecutablePath);
  }

  // This just needs to be some symbol in the binary; C++ doesn't
  // allow taking the address of ::main however.
  void *P = (void*) (intptr_t) GetExecutablePath;
  return llvm::sys::fs::getMainExecutable(Argv0, P);
}

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: None (13steinj)

Script and some relevant lines for reference: https://github.com/icecc/icecream/blob/d680e4fcb261d7de271ddce331f4a23adbfd573f/client/icecc-create-env.in#L313-L316

#80527 (more accurately combined with the minor commit 0f76d9f on top) results in a behavior change at least when building clang with -DCLANG_CONFIG_FILE_SYSTEM_DIR=/path/to/where/clang/will/be/installed/to/cfg, and supplying the produced default-clang (supplying merely clang is unaffected).

Prior behavior: the script ends up executing the equivalent of

/opt/clang-18.1.8/cfg/default-clang -print-prog-name=default-clang
# output: /opt/clang-18.1.8/cfg/default-clang

New behavior: no full path.

/opt/clang-19.1.1/cfg/default-clang -print-prog-name=default-clang
# output: default-clang

It is unclear if this behavior change to -print-prog-name is intentional hence why I'm filing this issue here first before filing a PR to icecc/icecream.

Resolution/workaround (at least for this execution of -print-prog-name is simple-- I'll just modify the script to call -no-canonical-prefixes -print-prog-name.

/opt/clang-19.1.1/cfg/default-clang -no-canonical-prefixes -print-prog-name=default-clang
# output: /opt/clang-19.1.1/cfg/default-clang

There is another use of -print-prog-name in this script that I appears unaffected as it requests the name of actual binaries (potentially outside of the clang installation directory? is the key factor?) rather than a clang config symlink to one.