In the install phase, when running miniruby (I believe to copy the already built gems/libraries to the right places):
/var/tmp/portage/dev-lang/ruby-2.2.4/ruby-2.2.4/lib/rubygems.rb:9:in `require`: incompatible library version - /var/tmp/portage/dev-lang/ruby-2.2.4/ruby-2.2.4/.ext/x86_64-linux-musl/thread.so (LoadError)
The error gets raised at around dln.c:1336 [if (ex && ex != ruby_xmalloc)]
Basically the ruby extension loader seems to be checking whether when the extension is loaded the ruby_xmalloc symbol is the same as was there already - to check for the correct version.
However, this is not the case. I do not know enough of dynamic loading in musl to tell why, but it's a bit strange because:
1. the command that fails is: ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb <...snipped full command...>
2. miniruby execve()'s into ruby22
3. ruby_xmalloc symbol exists in both miniruby and libruby22.so.2.2.0
So maybe the symbol table is not getting cleaned properly on execve()? I haven't read any musl source yet, so this is just speculation.
Happens for both ruby-2.2.4 and ruby-2.1.8 on musl-1.1.11.
The makefiles for ruby 2.0 and ruby 2.2 to execute miniruby [...] ./tool/runruby.rb are almost the same. However if you compare the strace output of doing so, on my machine at least, miniruby for 2.2 seems to have an extra call to open("/etc/ld-musl-x86_64.path").
However, I previously tried running the full miniruby command outside of the sandbox to test whether it worked when the original ebuild failed, and it actually installed /usr/lib/libruby2.2.so* . Which meant that the error above is actually invalid.
The actual error when the Makefile is executing miniruby [...] ./tool/runruby.rb is:
Error loading shared library libruby22.so.2.2: No such file or directory (needed by ./ruby22)
Patching the ebuild to export the LD_LIBRARY_PATH="$WORKDIR/$P" (which is where libruby22.so is located) before emake install makes this error go away.
I am currently doing more testing to see whether anything else is broken by this change.
*** This bug has been marked as a duplicate of bug 564272 ***