Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 571230

Summary: >=dev-lang/ruby-2.2.* musl - error loading shared library libruby22.so.2.2: no such file or directory
Product: Gentoo Linux Reporter: Vladimir Lushnikov <vladimir>
Component: Current packagesAssignee: Gentoo musl team <musl>
Status: RESOLVED DUPLICATE    
Severity: normal CC: musl, tsmksubc
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 430702    

Description Vladimir Lushnikov 2016-01-08 00:50:55 UTC
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
Comment 1 Vladimir Lushnikov 2016-01-09 13:19:12 UTC
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.
Comment 2 Felix Janda 2016-01-09 17:02:19 UTC
See also

https://bugs.gentoo.org/show_bug.cgi?id=564272#c10
Comment 3 Hans de Graaff gentoo-dev 2017-07-23 07:33:16 UTC

*** This bug has been marked as a duplicate of bug 564272 ***