Ruby 3.3.0 on MacOS Sequoia 15.1 (recently upgraded from Sonoma)

[robacarp]

Recently upgraded my M1 mac from Sonoma to Sequoia, and now I'm unable to install ruby.

The error is `checking whether the C compiler works ... no`.

cat /var/folders/dm/y0j_cpfd4bj_j3n1tdhfk0hh0000gn/T/ruby-build.20241111111000.1810.log
cd /var/folders/dm/y0j_cpfd4bj_j3n1tdhfk0hh0000gn/T/ruby-build.20241111111000.1810.nkD0dB
==> Downloading ruby-3.3.0.tar.gz...
-> curl -q -fL -o ruby-3.3.0.tar.gz https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0.tar.gz
-> tar xzf ruby-3.3.0.tar.gz
cd /var/folders/dm/y0j_cpfd4bj_j3n1tdhfk0hh0000gn/T/ruby-build.20241111111000.1810.nkD0dB/ruby-3.3.0
==> Installing ruby-3.3.0...
-> ./configure "--prefix=$HOME/.asdf/installs/ruby/3.3.0" --with-openssl-dir=/opt/homebrew/opt/openssl@3 --enable-shared --with-libyaml-dir=/opt/homebrew/opt/libyaml --with-gmp-dir=/opt/homebrew/opt/gmp --with-ext=openssl,psych,+
checking for ruby... /Users/robert/.asdf/shims/ruby
checking build system type... aarch64-apple-darwin24.1.0
checking host system type... aarch64-apple-darwin24.1.0
checking target system type... aarch64-apple-darwin24.1.0
checking for ld... ld
checking for llvm-ar... llvm-ar
checking for clang++... clang++
checking for llvm-nm... llvm-nm
checking for llvm-objcopy... llvm-objcopy
checking for llvm-objdump... llvm-objdump
checking for llvm-ranlib... llvm-ranlib
checking for llvm-strip... llvm-strip
checking for gcc... clang
checking whether the C compiler works... no
configure: error: in `/var/folders/dm/y0j_cpfd4bj_j3n1tdhfk0hh0000gn/T/ruby-build.20241111111000.1810.nkD0dB/ruby-3.3.0':
configure: error: C compiler cannot create executables
See `config.log' for more details
external command failed with status 77

I noted the section in the wiki on macOS:

• xcode-select --install: after the update, xcode did indeed need to be updated and opened up. Xcode 16.1 is installed now and this command says "note: Command line tools are already installed."
• brew install openssl@3 readline libyaml gmp autoconf: this was already true, as my machine had these previously. For the possibility that something is now out of date and needs to be re-compiled, I ran:

  brew uninstall --ignore-dependencies openssl@3 readline libyaml gmp autoconf 
  brew install openssl@3 readline libyaml gmp autoconf libyaml
  

  And the commands finished cleanly.

---

The wiki section for C compiler cannot create executables indicated that the answer should be obvious from the log output, which I think I believe, but in this case it's not obvious to me. I do not have anaconda installed.

The build folder also contained `config.log` for the output of the configure step which seems to indicate a library "System" is not found. I've attempted to extract the relevant parts of the output collapsed under here.

configure:6040: clang -V >&5
clang-12: error: argument to '-V' is missing (expected 1 value)
clang-12: error: no input files
configure:6051: $? = 1
configure:6040: clang -qversion >&5
clang-12: error: unknown argument '-qversion'; did you mean '--version'?
clang-12: error: no input files
configure:6051: $? = 1
configure:6040: clang -version >&5
clang-12: error: unknown argument '-version'; did you mean '--version'?
clang-12: error: no input files
configure:6051: $? = 1
configure:6071: checking whether the C compiler works
configure:6093: clang    conftest.c  >&5
dyld[2633]: symbol '__ZnwmSt19__type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /usr/lib/swift/libswiftCore.dylib is being set to 0xBAD4007.
dyld[2633]: symbol '__ZdlPvSt19__type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /usr/lib/swift/libswiftCore.dylib is being set to 0xBAD4007.
...snip ~400 lines of "use of symbol" variations...
ld: library 'System' not found

clang-12: error: linker command failed with exit code 1 (use -v to see invocation)

configure:6097: $? = 1

configure:6137: result: no

configure: failed program was:

| /* confdefs.h /

| #define PACKAGE_NAME ""

| #define PACKAGE_TARNAME ""

| #define PACKAGE_VERSION ""

| #define PACKAGE_STRING ""

| #define PACKAGE_BUGREPORT ""

| #define PACKAGE_URL ""

| / end confdefs.h.  */

|

| int

| main (void)

| {

|

|   ;

|   return 0;

| }

The error ld: library 'System' not found seems to be a rather generic error on google and unrelated to Sequoia. Here I should confess I've never had the pleasure of working with the macOS compiler chain myself and I'm out of my expertise. On a whim I'm going to try to uninstall xcode entirely and reinstall, but I'm grasping for straws. (and, update: reinstalling xcode seems to have done nothing).

[mislav]

Hi, this is indeed odd. I don't think you should be getting that ld error. Here is a log of my successful build of 3.3.0 on Sequoia that you can compare with yours and see if anything stands out to you: https://gist.github.com/mislav/a4760df55d3007cb3ce69463d9e9db8a

You can try sudo xcode-select --reset to select which version of compiler tools Xcode currently points to. If that doesn't help, check this thread for some debugging questions: pyenv/pyenv#2983 (comment). Note that that thread does not have an exact conclusion.

[robacarp]

@mislav thank you for the links and gist. Alas, that thread ended with the author noting their problems were solved with xcode-select and installing xcode, both of which I've done without success.

However, after reading the thread and clicking around a bit I ran into this comment on a similar thread which noted that uninstalling llvm solved their issue. This stood out at me because I recently updated llvm. This ultimately solved my issue.

I wanted to recreate the problem to see what signs I could have noticed which would have pointed me in this direction, but I have not yet been able to recreate the problem. Even brew link --force llvm@18 does not cause the issue again. Something about how/when I installed llvm and then later upgraded to Sequoia, caused llvm to interfere with the compiler.

At one point in the thread I read about a compiler tool being usurped by a corrupt path and audited which ld which still pointed to the correct /usr/bin/ld -- doubtless there was some other tool in the compiler chain that was indeed incorrect in this way, but re-linking llvm did not recreate the situation.

As always, thanks for your help @mislav