Swiftly is very invasive and makes unrelated compiles fail

Using Swift
1

I tried installing the latest ruby using `rbenv install 4.0.0`, and it always failed (macOS). I knew I could always install ruby this way though.
The part of the log didn’t really give a clear hint:

linking miniruby
Undefined symbols for architecture arm64:
  "_coroutine_transfer", referenced from:
      _fiber_setcontext in cont.o
      _thread_sched_wait_running_turn in thread.o
      _thread_sched_wait_running_turn in thread.o
      _ruby_coroutine_start in thread.o
      _ruby_coroutine_start in thread.o
      _nt_start in thread.o
…
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [miniruby] Error 1
external command failed with status 2

The internet had no usable information on how to fix this at all.

Then I remembered that a few months ago I tried compiling webrtc and by sheer coincidence found out that having swiftly installed on my machine was the reason the compilation failed. (And those compiles take waaaay longer than ruby :sweat_smile:)

Sure enough, ruby installed without a hitch once I used switly unlink and hash -r.

My question now is:
Is this a problem that can be fixed? This is imho a serious issue with the way swiftly seems to work. None of those projects I tried to compile use Swift. Those compiles should not break. There is also no indication where to look for the culprit (the full compile log of ruby never contains ‘swiftly’).

2 Likes