This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Apple M1: rbenv install 3.1.2 fails but installing ruby 3.1.2 from source succeeds
#2073
Comments
|
Please share full of your logs. |
|
They are in #1961 |
|
No, I want to see full of |
|
The following is the output of running The rbs-2.1.0 gem successfully compiles/links/loads, and thus the installation fully completes. However, in the ruby-build.20221029165815.98770.log log file from my previous comment (which is the output from So the question becomes: Why does the rbs-2.1.0 gem install successfully in the manual |
|
Thanks.
The above line is not related with ruby-build. Maybe, build system/toolchains of Ruby core does. I'll investigate its detail at next week. |
|
I just found that there is a major difference in the rbenv: manual: We can see that To recap: When compiling manually, the full If we then add Then we get the same error as with rbenv. So I think you may be right - it may not be a ruby-build issue after all. Please do try to check if it's an issue with ruby's build system or toolchain and let me know if I can help with troubleshooting since I can reproduce both scenarios consistently. |
|
Thanks for narrowing this down, @milosivanovic. |
|
@hsbt Were you ever able to take a look into this? I'm wondering whether there is something we should fix in ruby-build regarding this. In the meantime, this is what I suggest as workaround to affected users: #1961 (reply in thread) |
|
Yes, I'll track this issue now. But I couldn't reproduce this with Ventura 13.1 beta and Xcode 14 🤔 We will release all stable versions includes the fixes of Ventura and Xcode14 in Nov 2022. We will wait to try them for users who get same issues. |
|
@milosivanovic, you should follow up over here with your discussion over in ruby-build! #1961 |
|
@SeanSith Thanks for the ping. Closing since Ruby |
|
@mislav Unfortunately I'm still having the same issues noted in the original thread. The discussion over in ruby-build got me going (having to install openssl@3, disable shared-libraries), so it's not a straight-up My command was: |
|
@SeanSith Sorry for the trouble. Are you saying that downloading a Ruby 3.1.3 tarball and running It would help us if you posted the full failed build log using a gist. Thanks! |
|
@mislav the issue regarding the mismatched architecture still occurs on my machine with 3.1.3. I am still on Big Sur and still have Xcode 13.2.1. Steps to reproduce:
During the The contents of the The built shared library from the And it's showing as having arm64 architecture: |
@mislav: compilation of Ruby 3.1.3 using a new terminal, a tarball from ruby-lang.org, and the command you requested completes successfully. |
|
@milosivanovic I wonder why you have two paths for installation like:
What's your |
|
@hsbt I extracted the source in |
|
I also could install 🤔 |
|
@hsbt could you show the output of:
|
|
|
That is the same as me. What I don't understand is, if you look at my error logs that I posted above, the first indication of any problem is here: The "current directory" shows the working directory, and the line below shows the command executed (from builder.rb): If I manually go to that directory and run the command, the gem builds just fine. Take a look: You can see it says |
|
It looks like I will try to debug this method to try and find the difference between the environment it is in when the extconf.rb file is executed automatically via the initial |
|
Progress! First of all, and if I run this command on the terminal, it also fails (in the same way as #2073 (comment), which is good.) Now, why does calling extconf.rb via miniruby fail but not when called manually via the command-line as shown here #2073 (comment)? Digging further, extconf.rb eventually calls clang, and it's clang that complains about the cpu-subtype error. The clang command that extconf.rb calls is logged to mkmf.rb, so I copied it from there and ran it on my terminal. Similarly to running extconf.rb manually, running the clang command manually also works. Maybe there could be environment variable differences when miniruby runs versus when I run the clang command on the terminal directly? I modified https://github.com/ruby/ruby/blob/v3_1_3/lib/mkmf.rb#L615 to add I ran the clang command from mkmf.log again but this time prepended all the related environment variables from Now we need to figure out which of those environment variables is causing the problem that causes the incompatible cpu-subtype error with the clang command. |
|
Ok, the following works: but when we have So, it seems we cannot insert the library if we force it with Any ideas what |
|
Here is the full workaround with shared library support enabled:
It installs successfully without any errors. I was able to validate that it was built with shared libraries: I then redid it but this time building with just The Could you test the removal of |
|
Can you check your environmental variable of I still couldn't reproduce this with and this seems not ruby-build issue. We should move to https://bugs.ruby-lang.org/ |
|
The environment variable is not set in our standard bash terminal, which is why it was tricky to detect in the first place. It's the configure script which sets it: https://github.com/ruby/ruby/blob/master/configure.ac#L3050 Before After After That's where miniruby gets the And, yes, this is a ruby issue. I will report it at https://bugs.ruby-lang.org/ later today and propose that |
|
Why only your system affects with This environmental variable used by injecting another libraries like |
|
It's not only my system:
There are also quite a few who just gave a thumbs up without commenting. But yes, you're right - when we want to override the default memory allocator with jemalloc, we would need DYLD_INSERT_LIBRARIES. I'll report my findings to the ruby team and hopefully we can make more progress on this. |
|
Thanks so much @milosivanovic for excellent sleuthing and @hsbt for helping. Agreed this should be primarily handled in the Ruby issue tracker. But, is there something that we could do from ruby-build in the meantime as a workaround for all people affected? |
|
@hsbt I was able to compile and run ruby with jemalloc even after removing
Confirm jemalloc is in use by running So it does not appear DYLD_INSERT_LIBRARIES is necessary to exist in the manner that it does for jemalloc to be injectable. |
|
@mislav My (temporary) suggestion would be for ruby-build to strip out that line from the configure script, as per my repro steps. I'm open to hearing if there are other concerns. |
|
@milosivanovic Thanks for the suggestion. I do not know what DYLD_INSERT_LIBRARIES does, so I'd be careful about stripping it out and potentially negatively affecting builds on other platforms. I welcome suggestions of others who have more knowledge about this and why it's needed in the configure steps 🙇 |
|
@mislav The linux version of that variable is When a dynamically-built binary tries to reference a symbol from a shared library, the library that the symbol comes from can be overridden with To your point, if jemalloc can work without I'll be submitting all of these findings over to the ruby core team this weekend, so hopefully someone with more knowledge can help us understand what's happening. Thanks @hsbt and @mislav for your patience and help thus far! |
|
Hi there, I've investigated this issue a little bit, and finally got a repro on my end. Let me put my idea before going that direction. The essential requirement for repro is that SIP is disabled. TL;DR: Please re-enable SIP by following the official instruction and retry Why?
The error repoted during rbs_extension build is produced by the dynamic loader dyld. It says that the Mach-O executable file and the inserted Mach-O dylib by Okay, so we can't set Executable binaries that is code-signed with Apple certificates are called platform binaries: https://developer.apple.com/documentation/endpointsecurity/es_process_t/3228979-is_platform_binary The additional security protections, Hardened Runtime, disables Considering the above discussion, we have two workarounds for now: Workaround 1: Re-enable SIPThis is a little bit tricky, but enabling SIP would also solve the issue because it prevents loading incompatible library through (Potential) Workaround 2: Use clang compiled for arm64
So building with explicit compiler path may solve the issue: |
|
Tried the first workaround and was able to install MacOS: Ventura 13.0.1 and Xcode 14.1 - M1 |
|
@kateinoigakukun Those are excellent findings, thank you for diving deep into this with us. You are right, I have SIP disabled! I will try enabling SIP on the affected machine later today, but it sounds like @ydarbleoj already confirmed this - nice! That might also explain why some users who reinstalled their system saw the issue go away - they likely did not re-enable SIP, or did so after their installation of ruby succeeded. Regarding the architecture differences: The Your theoretical workaround definitely makes sense - I had wondered myself if clang had been built against Having said all of this, if with SIP enabled (which is the default on all macOS systems) the |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Hardware: Apple M1 MacBook Air running Big Sur 11.6.8
OpenSSL: Both 1.1 and 3.0 installed using brew with 3.0 as the linked default
Step 1: Run
rbenv install 3.1.2Step 2: Notice that
rbenv versionsdoes not show 3.1.2 because it failed to install using ruby-buildStep 3: Install 3.1.2 manually from source, bypassing ruby-build entirely
Step 4: Notice that
rbenv versionsnow shows 3.1.2 successfully installedPlease do not move this to the Discussions tab as the installation works when not using ruby-build. This leads me to believe that it is indeed a ruby-build issue.
For what it's worth, I can install ruby 3.1.2 this way with either OpenSSL 3.0 or OpenSSL 1.1 depending on what I provide in the configure step. I can provide
--with-openssl-dir=/opt/homebrew/opt/openssl\@1.1to override the 3.0 default that brew linked. Both work. However, again, with ruby-build the installation fails as per my report in #1961Thanks to #1961 (reply in thread) for finding this workaround that makes the source build usable with rbenv.
The text was updated successfully, but these errors were encountered: