Closed ioquatix closed 3 years ago
@jasl If you have time can you please review and confirm this fixes the issue?
@jasl If you have time can you please review and confirm this fixes the issue?
I'll test this today, do you mean I shoul use this commit of nio4r on my m1-crash-branch
and look it crash or not?
Yeah, try pointing your gemfile at this branch and use the native Ruby.
Yeah, try pointing your gemfile at this branch and use the native Ruby.
jasl@localhost:~/Workspaces/Ruby/CocoaPods on m1-crash-case$ ruby -v
ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.arm64e-darwin20]
jasl@localhost:~/Workspaces/Ruby/CocoaPods on m1-crash-case$ bundle exec irb
WARNING: This version of ruby is included in macOS for compatibility with legacy software.
In future versions of macOS the ruby runtime will not be available by
default, and may require you to install an additional package.
irb(main):001:0> require 'nio'
=> true
irb(main):002:0> NIO.engine
=> "libev"
irb(main):003:0>
It looks C-ext load OK now,
I also meet the weird bigdecimal
loading error to prevent me run CocoaPods tests (didn't see this before), I'm finding how to solve it.
BTW, To enable C-ext, you need comment these line https://github.com/socketry/nio4r/blob/master/lib/nio.rb#L28-L30
# if RUBY_PLATFORM =~ /darwin/ && RUBY_PLATFORM =~ /arm64/
# return true
# end
I'm going to merge this and cut a new release after I've tested it on the M1.
Description
It seems like
mkmf
will try to use theRbConfig
DLDFLAGS
which contains-arch
flags which confuse the linker, causing the resulting library to be completely empty. We delete those-arch
flags before generating the makefile, so that the resulting library is build only for the system's native architecture.See https://github.com/socketry/nio4r/issues/259 for more details.
Types of Changes
Testing