Bug #21111: RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs

• Status: Assigned
• Assignee: katei (Yuta Saito)
• Target version: -
• ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [arm64-darwin24]
• Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN

[stanhu (Stan Hu)]

As reported in https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/2222 and https://trac.macports.org/ticket/70750, we've had numerous macOS users experience problems with compiling Ruby C++ extensions after upgrading to XCode 16. Users have had to fix their XCode setups and reinstall Ruby when this happens.

It turns out that when Ruby can't build a CXX program, it essentially sets CXX to the false string. From https://github.com/ruby/ruby/blob/7317f96727725ca37ddb06011918deb841de371c/configure.ac#L1333-L1343:

AS_IF([test -n "${rb_there_is_in_fact_no_gplusplus_but_autoconf_is_cheating_us}"], [
    AC_MSG_NOTICE([Test skipped due to lack of a C++ compiler.])
],
[test -n "${CXX}"], [
    RUBY_WERROR_FLAG([
        AC_MSG_CHECKING([whether CXXFLAGS is valid])
        AC_LANG_PUSH(C++)
        AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include <cstdio>]], [[]])],
	    [AC_MSG_RESULT(yes)],[
            AC_MSG_RESULT(no)
            # The message mentions CXXFLAGS, but CPPFLAGS might also affects.
            AC_MSG_WARN([something wrong with CXXFLAGS="$CXXFLAGS"])
            CXX=false

This causes C++ extensions, such as unf_ext, to fail while attempting to compile native extensions. There are no error messages because false is executed, so users only see:

Installing unf_ext 0.0.8.2 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext
/Users/kerrizor/.rvm/rubies/ruby-3.3.7/bin/ruby extconf.rb
checking for -lstdc++... yes
creating Makefile

current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext
make DESTDIR\= sitearchdir\=./.gem.20250203-69237-u2oi17 sitelibdir\=./.gem.20250203-69237-u2oi17 clean

current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext
make DESTDIR\= sitearchdir\=./.gem.20250203-69237-u2oi17 sitelibdir\=./.gem.20250203-69237-u2oi17
compiling unf.cc
make: *** [unf.o] Error 1

unf_ext only checks whether RbConfig::CONFIG['CXX'] is defined, not that it is false: https://github.com/knu/ruby-unf_ext/blob/c72a36d0a5ea9fe3950611b0f289fc68a2595fcf/ext/unf_ext/extconf.rb#L36.

Questions:

1. Should CXX just be set to nil? Or should all C++ extensions be expected to check for false? The latter seems surprising to me.
2. Should there be a way to fail the Ruby build if a valid C++ compiler is not found?

[katei (Yuta Saito)]

At first, it’s rare to have a situation where Ruby itself can be built but no C++ compiler is available. The macOS example mentioned in the ticket is an unusual case caused by broken Command Line Tools.

Having said that, I agree that the current situation is not ideal.

I did some research how other languages with native extension support handle situations where a C++ compiler is missing:

• CPython: If no valid C++ compiler is found during the build, CPython guesses the compiler name from the value of CC and sets it as CXX. (e.g. when CC=gcc, then it defaults to CXX=g++)
• PHP: If no valid C++ compiler is found, CXX is set to an empty string (CXX="").
  CPython’s approach seems worth considering since it has the potential to recover more gracefully.

1. Should CXX just be set to nil? Or should all C++ extensions be expected to check for false? The latter seems surprising to me.

The current approach of setting CXX=false may seem tricky but actually makes some sense. This allows extensions to check the compiler’s sanity without inspecting CXX directly, e.g., using something like MakeMakefile["C++"].try_compile "".

2. Should there be a way to fail the Ruby build if a valid C++ compiler is not found?

IMO forcing the Ruby build to fail when no C++ compiler is found isn’t ideal since Ruby itself doesn’t depend on C++ at all.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned
• Assignee set to katei (Yuta Saito)