Bug #20961: MMTk build on macOS missing librubygc.mmtk.bundle

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 3.4.0dev (2024-12-18 master 9715131c32) +YJIT +MN +PRISM [arm64-darwin24.2.0]
• Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN

[shan (Shannon Skipper)]

Hi! I'm excited about the new modular GC feature. I just wanted to report that when I build Ruby 3.4.0-rc1 with MMTk on latest macOS 15.2 I seem to be encountering a linking issue. Whether I cargo build --release or ruby extconf.rb && make a target/release/libmmtk_ruby.dylib is created. A make modular-gc MODULAR_GC=mmtk then seems to expect a target/release/librubygc.mmtk.bundle, which doesn't exist. I briefly had it working but now can't reproduce the working order.

Reproduction steps:

brew install gmp jemalloc libffi libyaml openssl@3 readline rust zlib
curl https://cache.ruby-lang.org/pub/ruby/3.4/ruby-3.4.0-rc1.tar.xz | tar -x
cd ruby-3.4.0-rc1
./configure \
    --prefix="$HOME/.rubies/ruby-3.4.0-rc1" \
    --with-libyaml-dir="$(brew --prefix libyaml)" \
    --with-openssl-dir="$(brew --prefix openssl@3)" \
    --with-readline-dir="$(brew --prefix readline)" \
    --with-zlib-dir="$(brew --prefix zlib)" \
    --with-opt-dir="$(brew --prefix gmp):$(brew --prefix jemalloc)" \
    --with-jemalloc \
    --with-modular-gc="gc/mmtk/target/release"
cargo build --release --manifest-path=gc/mmtk/Cargo.toml
make -j miniruby modular-gc MODULAR_GC=mmtk

I keep getting errors similar to:

ruby_modular_gc_init: Shared library /Users/havenwood/src/ruby-3.4.0-rc1/gc/mmtk/target/release/librubygc.mmtk.bundle cannot be opened: dlopen(/Users/havenwood/src/ruby-3.4.0-rc1/gc/mmtk/target/release/librubygc.mmtk.bundle, 0x0009): tried: '/Users/havenwood/src/ruby-3.4.0-rc1/gc/mmtk/target/release/librubygc.mmtk.bundle' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/havenwood/src/ruby-3.4.0-rc1/gc/mmtk/target/release/librubygc.mmtk.bundle' (no such file), '/Users/havenwood/src/ruby-3.4.0-rc1/gc/mmtk/target/release/librubygc.mmtk.bundle' (no such file)

The latest nightly Ruby I tried produced the same missing .bundle error. I'm very much looking forward to 3.4.0 and the introduction of the new pluggable GC feature! Thank you!

[nobu (Nobuyoshi Nakada)]

shan (Shannon Skipper) wrote:

    --with-modular-gc="gc/mmtk/target/release"

IIRC, this option requires an absolute path.

[nobu (Nobuyoshi Nakada)]

I’m curious why this option is allowed to refer outside $(prefix). (and probably $(DESTDIR) too?)

[peterzhu2118 (Peter Zhu)]

IIRC, this option requires an absolute path.

No, if you pass a relative path it will convert it to an absolute path based on your current directory.

I’m curious why this option is allowed to refer outside $(prefix). (and probably $(DESTDIR) too?)

It's allowed because eventually we want to install GC implementations like gems, so it will be installed in a different directory like a C extension.

[peterzhu2118 (Peter Zhu)]

Thank you for trying this feature out. I think you're confused about how the configuration works, and that's our bad, we never documented anything.

The --with-modular-gc flag is used to specify a directory that the built GC library will be placed into, and it uses a different directory for the intermediate build artifacts (you don't need to specify this directory). It seems like you're trying to specify the Rust build directory for it?

I started working on a gc/README.md document. It's far from complete, but I wrote a "building guide" section which may help you in building this feature. Please let me know if you still run into issues.

[shan (Shannon Skipper)]

peterzhu2118 (Peter Zhu) wrote in #note-4:

I started working on a gc/README.md document. It's far from complete, but I wrote a "building guide" section which may help you in building this feature. Please let me know if you still run into issues.

You're right, I was just confused. I thought the option was to point to an alternative path to MMTk itself, and was curious why the default wasn't set to the one that ships with Ruby. It makes sense as you explain it in this thread and the new documentation. Thank you!

I do seem to run into a very similar error pointing the --with-modular-gc= option to the absolute path of an empty directory. The following was output from an attempt with a --with-modular-gc="/Users/havenwood/mmtk" flag ./configure.

❯ make modular-gc MODULAR_GC=mmtk
ruby_modular_gc_init: Shared library /Users/havenwood/mmtk/librubygc.mmtk.bundle cannot be opened: dlopen(/Users/havenwood/mmtk/librubygc.mmtk.bundle, 0x0009): tried: '/Users/havenwood/mmtk/librubygc.mmtk.bundle' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/havenwood/mmtk/librubygc.mmtk.bundle' (no such file), '/Users/havenwood/mmtk/librubygc.mmtk.bundle' (no such file)
make: *** [modular-gc] Error 1

[peterzhu2118 (Peter Zhu)]

Was the RUBY_GC_LIBRARY environment variable set when you ran make modular-gc MODULAR_GC=mmtk? The make modular-gc target uses Ruby to build the modular GC and it seems that the Ruby is trying to use the GC before it has been built.

[shan (Shannon Skipper)]

peterzhu2118 (Peter Zhu) wrote in #note-6:

Was the RUBY_GC_LIBRARY environment variable set when you ran make modular-gc MODULAR_GC=mmtk? The make modular-gc target uses Ruby to build the modular GC and it seems that the Ruby is trying to use the GC before it has been built.

I had exported CFLAGS with make settings as part of a successful previous install. Now it makes sense why it worked for me once and I couldn't reproduce my initial result. 🤦 I really appreciate you pointing me in the right direction. The issue was just my misunderstanding of steps paired with bumbling env vars.

I think this issue can be closed. Thank you and sorry for the noise.

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed