Bug #22311
closedBuild crashes on macOS 26 with the macOS 27 SDK because pipe2() and dup3() are unavailable
Description
Environment¶
- macOS 26.6.2
- Command Line Tools with MacOSX27.0.sdk (default
MacOSX.sdk) - Apple clang version 21.0.0 (clang-2100.3.34.2)
Steps to reproduce¶
Result¶
The build warns about dup3 and pipe2, and then miniruby crashes:
../io.c:389:19: warning: 'dup3' is only available on macOS 27.0 or newer [-Wunguarded-availability-new]
../io.c:432:18: warning: 'pipe2' is only available on macOS 27.0 or newer [-Wunguarded-availability-new]
../io.c:8141:18: warning: 'pipe2' is only available on macOS 27.0 or newer [-Wunguarded-availability-new]
...
make: *** [uncommon.mk:1331: builtin_binary.rbbin] Segmentation fault: 11
Cause¶
The macOS 27 SDK declares dup3() and pipe2() as available since macOS 27.0.
AC_CHECK_FUNCS links them without including headers, so configure defines HAVE_DUP3 and HAVE_PIPE2.
In io.c, they are weakly linked through the header and are NULL at runtime on macOS 26.
$ nm -m miniruby | grep -E '_(pipe2|dup3) '
(undefined) weak external _dup3 (from libSystem)
(undefined) weak external _pipe2 (from libSystem)
Notes¶
Autoconf 2.73 makes AC_CHECK_DECL report "no" for such functions on macOS.
Updated by nobu (Nobuyoshi Nakada) 7 days ago
Thank you for the info.
What should/can we do?
Use autoconf 2.73 to make the tarballs?
Or upgrade AC_PREREQ(2.67) to 2.73?
Updated by himura467 (Akito Shitara) 7 days ago
Using autoconf 2.73 with AC_CHECK_DECL as you suggested would fix it.
However, requiring 2.73 seems difficult for now, since the release tarballs are generated by 2.71, and Ubuntu 24.04/26.04 ship 2.71/2.72.
So I think a runtime check would be more practical, either:
Updated by etienne (Étienne Barrié) 7 days ago
For already released tarballs, I just want to mention for people out there looking for a solution, that the easiest way I found to get a working build is to use SDKROOT.
Tarball:
ruby-build:
ruby-build 4.0.6 ~/.ruby/ruby-4.0.6 -- SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk
ruby-install:
Updated by nobu (Nobuyoshi Nakada) 6 days ago
- Status changed from Open to Closed
Applied in changeset git|6bfde8d2a239a9e8549de1ae29acecdefdfb8086.
[Bug #22311] Check the availability of APIs added in macOS 27
To account for cases where binaries for older OS versions are built
using the new SDK, check at runtime whether the API functions are
available actually.
Updated by hsbt (Hiroshi SHIBATA) 5 days ago
The same report came to ruby-build as https://github.com/rbenv/ruby-build/issues/2640, and I worked it around there in https://github.com/rbenv/ruby-build/pull/2641. When the build host is older than macOS 27, ruby-build now exports ac_cv_func_dup3=no and ac_cv_func_pipe2=no before running configure. Neither function is callable at runtime on such a host whatever SDK is installed, so this only restores what the macOS 26 SDK used to produce.
The same two cache variables are enough when building a released tarball by hand.
Unlike SDKROOT, this needs no older SDK on the machine. A fresh Command Line Tools 27 install ships only MacOSX.sdk, which is 27.
In case a backport is considered, 6bfde8d2a239a9e8549de1ae29acecdefdfb8086 applies cleanly to v4.0.7 and v3_4_10. On v3_3_12 only the last hunk fails, and it is unnecessary there because ruby_popen_writer already goes through rb_cloexec_pipe.
Updated by hsbt (Hiroshi SHIBATA) 5 days ago
- Backport changed from 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN to 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED
Updated by hsbt (Hiroshi SHIBATA) 4 days ago
- Backport changed from 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED to 3.3: DONE, 3.4: DONE, 4.0: DONE
ruby_3_3 0c8ab2a111722f38b58738dd3d8fb77b79c11249, ruby_3_4 5a42e10000e344f2143b772b18b700a9f8e3c9cf and ruby_4_0 d50f404ca12c04e8bc3e8dd805879a660258b5c4 merged revision(s) 6bfde8d2a239a9e8549de1ae29acecdefdfb8086.