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. Reproducible: Always
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.
See also https://bugs.gentoo.org/show_bug.cgi?id=564272#c10
*** This bug has been marked as a duplicate of bug 564272 ***