Update makefile to use / fall back on built-in "ar"

$ gem install prism
<snip>
/bin/sh: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar: No such file or directory
$ ack Toolchains
ext/prism/Makefile
99:AR = /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar
$ which -a ar
/usr/bin/ar

# WORKAROUND
$ mkdir -p /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ ln -s $(which ar) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/
Successfully installed prism-0.26.0

To be clear, did this work with 0.25.0?

@ParadoxV5

@ParadoxV5 do you think you could take a look at this?

Running gem update daily for quite a while and first time this happened, so assume yes.

@forthrin

Also @forthrin that value is coming from RbConfig::CONFIG. Is it possible that you compiled Ruby with an ar and then somehow removed it?

@forthrin

Also @forthrin that value is coming from RbConfig::CONFIG. Is it possible that you compiled Ruby with an ar and then somehow removed it?

⬆. The new release switched from make-default AR & etc. to those specified by RbConfig::CONFIG, so this sort of problem arise if the current setup differs that built Ruby with.

~~This might be the same issue as the one failing CI in #2711.~~ [EDIT: It’s different.]
I’ll try some research on the Mac building environment. [Update: Homebrew/brew#17114 is reporting an incompatibility from Ubuntu.]
In the mean time, p RUBY_DESCRIPTION, RbConfig::CONFIG.slice('AR', 'ARFLAGS', 'CC') data could help us with confirmations.

I'm on macOS 14. gem says it's a "default gem". I have never installed it manually or used it directly. So everything that has happened with it has done so by default behind the scenes without my intervention or knowledge.

["ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23]",
 {"AR"=>
   "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar",
  "ARFLAGS"=>"rcu ",
  "CC"=>"clang"}]

gem says it's a "default gem"

Prism 0.19 is a default gem for Ruby 3.3, though gem lets us update default gems to never versions (e.g., Prism 0.26) if we wish.

@forthrin

 {"AR"=>
   "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar",
  "ARFLAGS"=>"rcu ",
  "CC"=>"clang"}]

This CC would search for “built-in clang” on the PATH, but AR is the full path to specifically the ar from Xcode.

Help us out @forthrin (and thank you for your patience):

How did you install Ruby 3.3?
- Is it possible that you compiled Ruby with an ar and then somehow removed it?
  - Did you switch toolsets after installing Ruby?
  - $ mkdir -p /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
    
    Had to create a directory that’s supposed to be managed by the Xcode app? 🤔
Are other C extension gems affected (without this workaround in-place)?

@kddnewton any other thoughts?

[arm64-darwin23]

So we support ARM? 👌

I'm still getting this error after trying the workaround.

I'm still getting this error after trying the workaround.

@nickmccurdy
Your setup is probably different then.
Neither OP nor the lead dev have replied, so while I (we?) ponder about how things work, can you also get us your p … data and question responses?

This is an issue indeed (a recurring one, sounds like), but I don’t want to just push some workaround (like what the title says). I want to cure it at its root.
Just that I’m not yet certain if it’s my fault or rather similar to Homebrew/homebrew-portable-ruby#187.

@ParadoxV5

@ParadoxV5: Happy to help

How did you install Ruby 3.3?

$ brew install ruby # before 3.3
$ brew upgrade # runs daily

Is it possible that you compiled Ruby with an ar and then somehow removed it?

Never compiled Ruby, at least not manually or intentionally. It's a cask.

Did you switch toolsets after installing Ruby? Had to create a directory supposed to be managed by Xcode?

Don't have Xcode, just CLT. Might have experimentally run xcode-select as suggested workarounds for various issues.

Are other C extension gems affected (without this workaround in-place)?

Like which? (Generally haven't had problems with Ruby or gems)

$ brew install ruby # before 3.3
[…]
Never compiled Ruby, at least not manually or intentionally. It's a cask.

Google says this’ll brew a formula, not a cask?
I don’t have experience in Mac development nor Homebrew, so this debugging is quite a challenge.

Might have experimentally run xcode-select as suggested workarounds for various issues.

That could be something. https://www.unix.com/man-page/OSX/1/xcode-select (from 2013?) implies that this Xcode util manages building tools including but not limited to /usr/bin/ar and /usr/bin/clang. But 🤔

Your ar exists in /usr/bin/ but not in Xcode where /usr/bin/* refers to.
Your CC searches the PATH while your AR is pinned to Xcode.

Like which?

Anything that says “Building native extensions. This could take a while” when gem installed (or gem updated).

Does brew upgrade ruby include gem update?

[Edit]
Actually, it look like a malformed AR entry won’t affect most C extension gems because they are dynamically linked (i.e., built as .so) which does not need ar.
Otherwise, mkmf doesn’t seem to have any mechanism to fall back to PATH ar if the rbconfig AR is broken (like what this issue requested (originally)).

Fixed on main

What date will this be available in the central Gem repository? (It's breaking gem update atm.)

I'll make a new release today, I'll update the ticket when I do.

Released with v0.27.0

$ gem install prism
Successfully installed prism-0.27.0

Great detective work, you guys.

@kddnewton

you guys.

No thank you, @kddnewton did all the thing.

Though I’m still puzzled on how your rbconfig ended up like that.

Also, the PR logs told that you needed the AR ?= ar line, but it was supposed to not matter for GNU make.
What’s your make --version? Could that be a possiblility?
(The README.md specifies GNU make.)

@forthrin

@forthrin I have been trying to understand this issue in more details (here).
Could you share the output of ruby -ve 'pp RbConfig::CONFIG'?
And also the output of these 5 commands:

xcode-select --print-path
ls $(xcode-select --print-path)
ls $(xcode-select --print-path)/bin
ls $(ruby -e 'puts RbConfig::CONFIG["CC"]')
ls $(ruby -e 'puts RbConfig::CONFIG["AR"]')

?

I wonder if maybe an incorrect xcode-select or an XCode update removing an older toolchain could cause this.
The part about CC existing and AR not is really puzzling.

$ xcode-select --print-path
/Library/Developer/CommandLineTools

$ ls $(xcode-select --print-path)
Library SDKs    usr

$ ls $(xcode-select --print-path)/bin
ls: /Library/Developer/CommandLineTools/bin: No such file or directory

$ ls $(ruby -e 'puts RbConfig::CONFIG["CC"]')
ls: clang: No such file or directory

$ ls $(ruby -e 'puts RbConfig::CONFIG["AR"]')
ls: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar: No such file or directory

FYI:

$ ls -l /Library/Developer/CommandLineTools/usr/bin
/Library/Developer/CommandLineTools/usr/bin/ar
/Library/Developer/CommandLineTools/usr/bin/clang
# snip

Thank you, that confirms that RbConfig::CONFIG["CC"] is clang and so that just works.
And RbConfig::CONFIG["AR"] is /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar, which is a broken value as (from what I understood) you never had a file at that path on that machine.

This seems very much a case of Homebrew/homebrew-portable-ruby#187 or very similar.
IOW it's a bug of that precompiled ruby you got that RbConfig::CONFIG["AR"] is an invalid path.
Although ruby in your PATH is most likely brew install ruby from what you said earlier, not that homebrew-portable-ruby.
So then it'd be a bug of https://github.com/Homebrew/homebrew-core/blob/master/Formula/r/ruby.rb, specifically that the binary (bottle) contains such invalid paths.

I used GitHub Actions (with mxschmitt/action-tmate@v3) to check and it's a clear issue in Homebrew ruby bottles since 3.2:

$ for v in 3.0 3.1 3.2 3.3; do echo $v; /opt/homebrew/opt/ruby@$v/bin/ruby -e 'pp RbConfig::CONFIG["CC"]'; done       
3.0
"clang -fdeclspec"
3.1
"clang"
3.2
"clang"
3.3
"clang"

$ for v in 3.0 3.1 3.2 3.3; do echo $v; /opt/homebrew/opt/ruby@$v/bin/ruby -e 'pp RbConfig::CONFIG["AR"]'; done       
3.0
"ar"
3.1
"ar"
3.2
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar"
3.3
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar"

I filed Homebrew/homebrew-core#170978

@eregon

@eregon: Kudos for digging deeper and locating the core issue!

Navigation Menu

Repository navigation

Update makefile to use / fall back on built-in "ar" #2716

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Update makefile to use / fall back on built-in "ar" #2716

Description

Activity

kddnewton commented on Apr 19, 2024

kddnewton commented on Apr 19, 2024

forthrin commented on Apr 19, 2024

kddnewton commented on Apr 19, 2024

ParadoxV5 commented on Apr 19, 2024

forthrin commented on Apr 19, 2024

ParadoxV5 commented on Apr 19, 2024

ParadoxV5 commented on Apr 19, 2024

nickserv commented on Apr 19, 2024

ParadoxV5 commented on Apr 20, 2024

forthrin commented on Apr 20, 2024

ParadoxV5 commented on Apr 20, 2024

12 remaining items

kddnewton commented on Apr 23, 2024

forthrin commented on Apr 23, 2024

kddnewton commented on Apr 23, 2024

kddnewton commented on Apr 23, 2024

forthrin commented on Apr 24, 2024

ParadoxV5 commented on Apr 24, 2024

eregon commented on May 6, 2024

forthrin commented on May 6, 2024

eregon commented on May 6, 2024

eregon commented on May 6, 2024

eregon commented on May 6, 2024

forthrin commented on May 7, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions