Seg fault with statically linked version of Ruby

[jkehres]

Describe the bug

I'm using a statically linked version of Ruby 2.7.2 on macOS. I can build the gem (it links against libruby.2.7-static.a) but when I require the gem, I get a seg fault at lib/wasmer.rb:31. If I use a dynamically linked version of Ruby 2.7.2 (where the gem links against libruby.2.7.dylib) everything works fine.

Steps to reproduce

1. On a Mac, build a statically linked version of Ruby 2.7.2 (e.g. RUBY_CONFIGURE_OPTS="--disable-shared" ruby-build 2.7.2 /path/to/install)
2. Verify that /path/to/install/lib contains libruby.2.7-static.a
3. Build the gem against this version of Ruby
4. Open an IRB session
5. Run require 'wasmer'

Expected behavior

No seg fault occurs.

Actual behavior

Seg fault occurs.

Additional context

Repeating the same steps with RUBY_CONFIGURE_OPTS="--enabled-shared" works just fine.

[Hywan]

Hello,

We use rutie to build this extension. Reading its documentation (https://github.com/danielpclark/rutie#dynamic-vs-static-builds):

Dynamic vs Static Builds

Ruby needs to be compiled with the --enable-shared option. Dynamic linking to the Ruby library provides the best performance and best support. Static build support is incomplete for now.

If using RBENV then the following is recommended:

CONFIGURE_OPTS=--enable-shared rbenv install 2.7.1

I'm sad to say that either you must use the dynamic library, or we need to contribute to rutie to fix the issues.

[Hywan]

Note: We must at least test that Ruby is compiled with the --enable-shared option to raise an approriate error message rather than a segfault. We may be able to find this information with RbConfig::CONFIG['ENABLE_SHARED']. Are you willing to open a PR for that (just asking)?

[sandstrom]

For future reference, here are the relevant issues in rutie: https://github.com/danielpclark/rutie/issues?q=is%3Aissue+is%3Aopen+label%3A%22static+build+issue%22

And here is a similar (now closed) issue in wasmer-ruby: #56

[Hywan]

Thanks :-)!