From: "katei (Yuta Saito)" Date: 2022-09-17T11:29:27+00:00 Subject: [ruby-core:109939] [Ruby master Bug#18912] Build failure with Xcode 14 and macOS 13 (Ventura) Beta Issue #18912 has been updated by katei (Yuta Saito). I've been doing some digging around the `TestProcess#test_daemon_noclose` test failure. Minimum reproducible code is here ``` Process.daemon(false, true) Dir.pwd ``` And got some facts: - On macOS, you should not use Objective-C classes for the first time in a process forked from a multithreaded process without exec - Because the +initialize mechanism called the first time you use an Objective-C class is not async signal safe. - Sources: [detailed blog post](http://sealiesoftware.com/blog/archive/2017/6/5/Objective-C_and_fork_in_macOS_1013.html), [comments in objc4 source code](https://github.com/apple-oss-distributions/objc4/blob/8701d5672d3fd3cd817aeb84db1077aafe1a1604/runtime/objc-initialize.mm#L426-L458) - CRuby on macOS is always multithreaded due to the timer thread. - `Kernel.fork` and `Process.daemon` can create "forked process without exec". - In other words, using Objective-C API after forked process may cause deadlock. - CoreFoundation API used by `Dir.pwd` now depends on Objective-C classes from Ventura. (NEW in Ventura) So, I guess this means that the potential deadlock was everywhere even before Ventura, and it was not caught in test suites. However it was finally revealed, thanks(?) to the CoreFoundation change introduced in Ventura. IMHO this unsafe-ness is a problem that can only be solved on the user program side, not CRuby. So we can leave this problem to user responsibility and update the test case to be Objective-C friendly... (I know this is not ideal solution, so let me know if you have a better solution) ---------------------------------------- Bug #18912: Build failure with Xcode 14 and macOS 13 (Ventura) Beta https://bugs.ruby-lang.org/issues/18912#change-99186 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Today, I tried to build ruby master with macOS 13 (Ventura) Beta. It breaks the build status caused by Xcode 14 beta changes. TL;DR: We should add `--without=+,bigdecimal --enable-shared` to the `configure` option. 1. Build failed without `--enable-shared`. I build ruby master without `--enable-shared` option. I got the following error. ``` (snip) linking shared-object -test-/arith_seq/extract.bundle Undefined symbols for architecture arm64: "_rb_arithmetic_sequence_extract", referenced from: _arith_seq_s_extract in extract.o "_rb_ary_new_capa", referenced from: _arith_seq_s_extract in extract.o "_rb_ary_store", referenced from: _arith_seq_s_extract in extract.o "_rb_define_singleton_method", referenced from: _Init_extract in extract.o "_rb_path2class", referenced from: _Init_extract in extract.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` @katei says this error affects with `-undefined dynamic_lookup` flags. 2. Build error with bigdecimal With `--enabled-shared` resolved the first error. But I got the another build failure. ``` compiling bigdecimal.c In file included from bigdecimal.c:13: In file included from ./bigdecimal.h:14: ./missing.h:127:1: error: static declaration of 'rb_rational_num' follows non-static declaration rb_rational_num(VALUE rat) ^ ../.././include/ruby/internal/intern/rational.h:128:7: note: previous declaration is here VALUE rb_rational_num(VALUE rat); ^ In file included from bigdecimal.c:13: In file included from ./bigdecimal.h:14: (snip) ``` It's affected with `static inline` declaration in missing.h of bigdecimal. 3. test failure with mjit I could build with `--with-out-ext=+,bigdecimal --enable-share` option. But I also got the test failure with mjit. ``` [215/402] TestMJIT#test_lambda_longjmp = 0.19 s 192) Failure: TestMJIT#test_lambda_longjmp [/Users/hsbt/Documents/github.com/ruby/ruby/test/ruby/test_mjit.rb:1045]: Expected 1 times of JIT success, but succeeded 0 times. script: """ fib = lambda do |x| return x if x == 0 || x == 1 fib.call(x-1) + fib.call(x-2) end print fib.call(5) """ stderr: """ Undefined symbols for architecture arm64: "_mjit_call_p", referenced from: __mjit0 in _ruby_mjit_p39885u0-643ab5.o _vm_sendish in _ruby_mjit_p39885u0-643ab5.o ``` I already shared this to @k0kubun . macOS 13 beta is still development status. I will track this until the official release date. -- https://bugs.ruby-lang.org/ Unsubscribe: