Avoid following compiler symlinks

[manopapad]

Certain vendors (e.g. Apple, HPE Cray) have the bad habit of providing a single compiler entrypoint (clang in the case of Apple's XCode), and a bunch of symlinks to that one entrypoint for the various languages (e.g. cc and c++ both link to clang). That is fine, however inside the shared entrypoint the code is taking cases depending on which symlink was used to invoke it. In the case of XCode, invoking clang through cxx will activate C++-mode, whereas invoking it through cc (or simply using the shared entrypoint directly) will activate C-mode, which will not link against the standard C++ library:

~/Desktop> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ must-be-compiled-with-cpp.cc
~/Desktop> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc must-be-compiled-with-cpp.cc
Undefined symbols for architecture x86_64:
  "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced from:
      std::__1::ctype<char> const& std::__1::use_facet[abi:v15006]<std::__1::ctype<char>>(std::__1::locale const&) in must-be-compiled-with-cpp-5cff82.o
  "std::__1::ios_base::getloc() const", referenced from:
      std::__1::basic_ios<char, std::__1::char_traits<char>>::widen[abi:v15006](char) const in must-be-compiled-with-cpp-5cff82.o
  "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::__init(unsigned long, char)", referenced from:
      std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::basic_string[abi:v15006](unsigned long, char) in must-be-compiled-with-cpp-5cff82.o
  ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
~/Desktop> ls -alh /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
lrwxr-xr-x  1 root  wheel     5B Apr 11 10:13 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -> clang
~/Desktop> ls -alh /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
lrwxr-xr-x  1 root  wheel     5B Apr 11 10:13 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -> clang

What this all means is that we need to avoid following symlinks on compiler executables.

If there was a fundamental reason why we were doing this in this file, my case would also be solved if we changed the fuzzy matching for */cc to explicitly match only /usr/bin/cc.

This change also makes sure ccache will be applied on the propagated value of CC/CXX, if it exists.

[manopapad]

@trxcllnt ready for another pass

[jjwilke]

This seems fine to me. On my mac, these don't seem to be symlinks so I can't reproduce the issue or test the fix.