Project

General

Profile

Actions

Bug #19794

open

Ruby 3.2.2 fails to build on macOS Sonoma betas

Added by jhaungs (Jim Haungs) over 1 year ago. Updated about 1 year ago.

Status:
Assigned
Target version:
-
[ruby-core:114332]

Description

With Big Sur, Apple deprecated putting dylibs in /usr/local/lib. In Sonoma (beta 4), this directory has disappeared completely. However, ruby's configure script depends on its existence. So, virtually every ruby installer (RVM, rbenv, asdf, ruby-build, and even building from source tarball) fails.

When building ruby 3.2.2 from source, the configure step outputs the irritatingly useless "something wrong with LDFLAGS" error message and fails to build.

The solution was to cd /usr/local; sudo mkdir lib to create the missing lib directory under /usr/local.

It would be nice to remove this dependency from the configure script.


Related issues 1 (1 open0 closed)

Related to Ruby master - Bug #20631: Build failure with Xcode 16 beta and macOS 15 (Sequoia) BetaAssignedhsbt (Hiroshi SHIBATA)Actions

Updated by ecnelises (Chaofan QIU) over 1 year ago

ld maintains a list of directories to search for a library or framework to use. The default library search path is /usr/lib then /usr/local/lib. The -L option will add a new library search path. The default framework search path is /Library/Frameworks then /System/Library/Frameworks.

I'm using Sonoma beta with Xcode 15 beta, it seems system ld still tries to look for /usr/local/lib and emits warning when it doesn't exist.

Updated by jhaungs (Jim Haungs) over 1 year ago

Thanks for the analysis. I've reported this as FB13016123 in Apple's feedback system.

Diagnosing situations like this would be easier if the configure script did a better job of surfacing the LD warnings. The "something wrong with LDFLAGS" message is too vague to be useful.

Updated by hsbt (Hiroshi SHIBATA) about 1 year ago

  • Status changed from Open to Assigned
  • Assignee set to nobu (Nobuyoshi Nakada)

We should avoid to non-existence directory for fresh install of macOS.

@nobu (Nobuyoshi Nakada) Can you investigate this?

Updated by monfresh (Moncef Belyamani) about 1 year ago

I think something else is going on here. On a fresh macOS installation, the /usr/local directory has been completely empty for several macOS versions now, since at least Catalina, and most likely earlier versions as well. I know this because I specialize in Ruby installation on Mac. I'm the creator of "Ruby on Mac" (rubyonmac.dev).

I just installed Ruby 3.2.2 on macOS Sonoma 14.0 (release candidate) without any issues using my Ruby on Mac product. I also tried it directly with rbenv and it worked. This is on an M1 Mini with nothing in /usr/local and with Homebrew installed in /opt/homebrew

If every version manager and installing from source failed, then perhaps there was a bug in Sonoma beta 4, or an incompatibility with Homebrew, or something wrong, outdated, misconfigured, or missing in @jhaungs (Jim Haungs) dev setup on their Mac. If they're on an Intel Mac and /usr/local was empty, that would indicate that Homebrew wasn't installed yet. Another possible reason for this failure is that /usr/local/lib is a symlink to some file. This might sound farfetched, but I had a customer who had done just that.

In my experience helping thousands of people over the past 12 years, the vast majority of installation issues are due to missing prerequisites, outdated or misconfigured tools, and setting incorrect or unnecessary Ruby compilation flags, either globally in the shell startup file or in the terminal as part of the installation command.

Updated by jhaungs (Jim Haungs) about 1 year ago

Thanks @monfresh (Moncef Belyamani).

I tried it on Sonoma RC, and it installed fine. The /usr/local/lib dir is present. I have had no feedback on FB13016123, but I suspect Apple fixed this after Sonoma Beta 4.

One of my reasons for filing this was the hope that the configure script could be improved to surface errors from LD as something more meaningful than "Something wrong with LDFLAGS." It takes way too long to reverse-engineer the configure script to figure out the root cause of the error.

Updated by nobu (Nobuyoshi Nakada) about 1 year ago

The latest Xcode seems taking care about only /usr/local/lib differently.

$ echo 'int main(void) {return 0;}' > main.c

$ clang --version
Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: arm64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

$ LANG=C ls /usr/local/lib /non/existent/lib
ls: cannot access '/usr/local/lib': No such file or directory
ls: cannot access '/non/existent/lib': No such file or directory
bash: exit 2

$ clang -L /usr/local/lib -L /non/existent/lib main.c 
ld: warning: search path '/non/existent/lib' not found
Actions #7

Updated by hsbt (Hiroshi SHIBATA) 4 months ago

  • Related to Bug #20631: Build failure with Xcode 16 beta and macOS 15 (Sequoia) Beta added
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0