We've standardised on gcc as our compiler. But there is at least one case where it's insufficient, and that is for compiling modern Objective C code. For that, we'll need LLVM and clang.
LLVM and clang behave very differently from gcc, so there are some extra steps we need to do. First off, they're not built for a single target. Instead, you select the target at runtime. While flexible, it means you cannot rely on built-in details like default include and library paths. We seem to be able to resolve most of this through two extra steps: a) We create target specific symlinks, e.g. "arm-none-linux-gnueabi-clang++" that points at "clang++". This makes single assume an implicit "-target arm-none-linux-gnueabi". b) We create config files for each target that specify the remaining necessary arguments. Mainly the "--sysroot" argument. clang can be built to implicitly load /etc/clang/<target>.cfg where we can put stuff. This solves most issues. For ARM we need a bit extra, though, as the target triple doesn't say everything we want about the target system. For gcc we provide this when building gcc, but for clang we need to add these extra settings to the config file.
The next major issue is the C++ standard library. The LLVM project has libc++, but we are currently using libstdc++ that's included with gcc. We likely don't want to have to keep track of multiple libraries, if nothing else to make sure everything can link safely. Fortunately, clang supports using libstdc++. It's even the default on Linux systems. It does some magical heuristics to find where gcc is, and hence the libstdc++ headers and libraries. But they seem to work fine with our setup, so no need to fiddle anything extra with that. But that's only for Linux. For macOS it assumes libc++. We can easily switch this default to libstdc++, but the heuristics fail to find the headers and libraries. Looking at the clang code, the heuristics are per platform. So that's why we're seeing different behaviours. And the heuristics for macOS seem very rudimentary and are as minimal as possible to only support the libstdc++ that Apple included back many years ago. I can trick it, though, but putting the new libstdc++ in the same place at the old stuff. That gets everything building and linking correctly. At which point the next issue shows up. The macOS heuristics have no support for the "-static-libstdc++" flag. Something we absolutely need as we'll be using our own version. I even found an upstream bug report for this: https://github.com/llvm/llvm-project/issues/76945
Something is broken with the MinGW heuristics as well. They do some attempt at finding gcc, but not in the standard directories.
