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 packages	Assignee:	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 ***