ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
* [ruby-core:120873] [Ruby master Bug#21111] RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs
@ 2025-02-03 22:47 stanhu (Stan Hu) via ruby-core
  0 siblings, 0 replies; only message in thread
From: stanhu (Stan Hu) via ruby-core @ 2025-02-03 22:47 UTC (permalink / raw)
  To: ruby-core; +Cc: stanhu (Stan Hu)

Issue #21111 has been reported by stanhu (Stan Hu).

----------------------------------------
Bug #21111: RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs
https://bugs.ruby-lang.org/issues/21111

* Author: stanhu (Stan Hu)
* Status: Open
* 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
----------------------------------------
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?




-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2025-02-03 22:48 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-02-03 22:47 [ruby-core:120873] [Ruby master Bug#21111] RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs stanhu (Stan Hu) via ruby-core

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).