[runtimes] Append -nostd*++ flags only for Clang

[mgorny]

Append -nostdlib++ and -nostdinc++ flags to CMAKE_REQUIRED_FLAGS
only if we are actually building with Clang. These flags are also
passed to the C compiler, which is not allowed in GCC. Since CMake
implicitly performs some tests using the C compiler, this can lead
to incorrect check results. This should be safe, since FWIU we only
need them when bootstrapping Clang.

Even though we know that Clang supports these flags, we still need
to explicitly check if they work, as in some scenarios adding
-nostdlib++ actually breaks the build. See PR #108357 for examples
of that.

Fixes #90332

[jhuber6]

What do we need the required flags for again? I'm guessing this is just for checking C/C++ flags?

[mgorny]

That's my understanding — we're adding them, so CMake checks don't fail prior to the runtimes being built.

Unfortunately, looks like my idea breaks some stuff still. That said, I'm not 100% convinced it just doesn't reveal an existing bug:

Performing C++ SOURCE FILE Test CXX_SUPPORTS_NOSTDINCXX_FLAG failed with the following output:
Change Dir: /home/runner/_work/llvm-project/llvm-project/build/generic-asan/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/local/bin/ninja cmTC_779c6 && [1/2] Building CXX object CMakeFiles/cmTC_779c6.dir/src.cxx.o
[2/2] Linking CXX executable cmTC_779c6
FAILED: cmTC_779c6 
: && /usr/bin/clang++-21 -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fno-omit-frame-pointer -fsanitize=address -fdiagnostics-color -ffunction-sections -fdata-sections  --start-no-unused-arguments --unwindlib=none --end-no-unused-arguments  CMakeFiles/cmTC_779c6.dir/src.cxx.o -o cmTC_779c6   && :
/usr/bin/ld: /usr/lib/llvm-21/lib/clang/21/lib/linux/libclang_rt.asan-x86_64.a(sanitizer_unwind_linux_libcdep.cpp.o): undefined reference to symbol '_Unwind_Backtrace@@GCC_3.3'
/usr/bin/ld: /lib/x86_64-linux-gnu/libgcc_s.so.1: error adding symbols: DSO missing from command line
clang++-21: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

I'm guessing that the code relied on -nostdlib++ just hiding the issue.

[Meinersbur]

I think it was added because originally, LLVM_ENABLE_RUNTIMES was invented for libc++(abi). It is C++, but obviously cannot link against libc++.so before libc++.so is built. For any library that is not libc++ but uses the C++ standard library (flang-rt, hwloc through openmp, maybe others), as long as there is a libc++/libstdc++ installed on the system and found by Clang, it can use that.

If we want those runtimes to link together with just-built libc++, we need a 4-stage bootstrapping build (clang -> compiler-rt builtins -> libc++ -> flang-rt/openmp). Or, at least this seems to be the current approach, make the configure step not depend on the existence of the C++ standard library, but for build-time, one can add a dependency to libc++ if built in the same runtimes build.

Also see #131010

Note that you can temporarily get rid of the flags using cmake_push_check_state(RESET).

There is a mechanism to add flags only for C++: $<$<COMPILE_LANGUAGE:CXX>:-nostdlib++>. Haven't tried whether this also works for CMAKE_REQUIRED_FLAGS.

[mgorny]

Oh, that's an interesting approach. I need to set the build right locally to reproduce the issue, then I'll try that.

[mgorny]

There is a mechanism to add flags only for C++: $<$<COMPILE_LANGUAGE:CXX>:-nostdlib++>. Haven't tried whether this also works for CMAKE_REQUIRED_FLAGS.

Unfortunately, it doesn't seem to:

CMake Error:
  Running

   '/usr/bin/ninja' '-C' '/home/mgorny/llvm-project/build/runtimes/runtimes-bins/CMakeFiles/CMakeScratch/TryCompile-wJiSEf' '-t' 'recompact'

  failed with:

   ninja: error: build.ninja:50: bad $-escape (literal $ must be written as $$)

  



CMake Error at /usr/share/cmake/Modules/Internal/CheckSourceCompiles.cmake:108 (try_compile):
  Failed to generate test project build system.
Call Stack (most recent call first):
  /usr/share/cmake/Modules/Internal/CheckCompilerFlag.cmake:18 (cmake_check_source_compiles)
  /usr/share/cmake/Modules/CheckCXXCompilerFlag.cmake:55 (cmake_check_compiler_flag)
  CMakeLists.txt:167 (check_cxx_compiler_flag)

[mgorny]

Hmm, perhaps another approach would be to apply them only when the compiler is actually clang.

[mgorny]

Ok, let's see if this works. I've combined check for clang with explicit checks to prevent the fallout from #108357.

I suppose another approach would be to test both the C and C++ compiler, and add the flags only if both work.

[jhuber6]

I think it was added because originally, LLVM_ENABLE_RUNTIMES was invented for libc++(abi). It is C++, but obviously cannot link against libc++.so before libc++.so is built. For any library that is not libc++ but uses the C++ standard library (flang-rt, hwloc through openmp, maybe others), as long as there is a libc++/libstdc++ installed on the system and found by Clang, it can use that.

If we want those runtimes to link together with just-built libc++, we need a 4-stage bootstrapping build (clang -> compiler-rt builtins -> libc++ -> flang-rt/openmp). Or, at least this seems to be the current approach, make the configure step not depend on the existence of the C++ standard library, but for build-time, one can add a dependency to libc++ if built in the same runtimes build.

I don't think we fully need to bootstrap it, we already have libc++ built on top of libc and I built flang-rt on top of libc++ built on to of libc. Shouldn't these just be a list of CMake dependencies? The runtimes order is deterministic so we just move those libraries earlier in the chain. Having the builtins separate only makes sense because oftentimes those are necessary for passing some feature checks by the compiler.

[mgorny]

Okay, I think this version does not introduce any buildbot regressions. It also works for Gentoo.

[thesamesam]

It looks fine (enough) for me if others are happy.

[mgorny]

@jhuber6, do you have an opinion on this change?

[jhuber6]

Seems innocuous enough.

[mgorny]

Okay, thanks. Let's give it a shot.