Bug 998845 - Binary extensions cannot be loaded from %gem_extdir from an scl namespace other than ruby193
Binary extensions cannot be loaded from %gem_extdir from an scl namespace oth...
Status: CLOSED ERRATA
Product: Red Hat Software Collections
Classification: Red Hat
Component: ruby (Show other bugs)
ruby193
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 1.1
Assigned To: Josef Stribny
Iveta Wiedermann
:
Depends On:
Blocks: 1034639
  Show dependency treegraph
 
Reported: 2013-08-20 04:08 EDT by Mrugesh Karnik
Modified: 2016-01-04 00:51 EST (History)
5 users (show)

See Also:
Fixed In Version: ruby193-ruby-1.9.3.484-43.el6,ruby193-ruby-1.9.3.484-43.el7
Doc Type: Bug Fix
Doc Text:
Cause: When binary extensions are installed under %gem_extdir/lib/ in a software collection that installs under a namespace other than ruby193, it cannot be loaded. Consequence: Collection which depends on ruby193 would not be able to properly use rubygem- packages, which ships binary extensions. Fix: RubyGems from ruby193 collection can now properly discover locations of binary extensions for dependent collections. Result: rubygem- package from depending collections, which ships with binary extensions, can be properly loaded now.
Story Points: ---
Clone Of:
: 1034639 (view as bug list)
Environment:
Last Closed: 2014-06-04 03:15:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mrugesh Karnik 2013-08-20 04:08:06 EDT
Description of problem:

When binary extensions are installed under %gem_extdir/lib/ in a software collection that installs under a namespace other than ruby193, it cannot be loaded.



How reproducible:

Always.



Steps to Reproduce:

1. Create a software collection (foo) that installs ruby gems under it's own namespace, eg /opt/rh/foo. The `enable' script shipped with the foo-runtime package updates the GEM_PATH environment variable eg

export GEM_PATH=/opt/rh/foo/root/usr/share/gems:`ruby -e "print Gem.path.join(':')"`


2. Create a gem package (foo-rubygem-bar) under this collection that installs a binary extension under %gem_extdir, eg 

/opt/rh/foo/root/usr/lib64/gems/exts/bar-1/lib/bar.so


3. Enable ruby193 and foobar scls and try to load the gem eg.

$ scl enable ruby193 foo irb
irb > require 'foo'



Actual results:

Gem fails to load with an exception that says that the binary extension cannot be found.



Expected results:

The binary extension and the gem should be loaded.



Additional info:

Making the extension available under %gem_libdir solves this problem, but it violates the Fedora Ruby packaging guidelines. A temporary workaround is to either keep the extension under %gem_libdir or make a symlink to the extension installed in %gem_extdir in %gem_libdir eg

mv %{buildroot}%{gem_libdir}/bar.so %{buildroot}%{gem_extdir}/lib
pushd %{buildroot}%{gem_libdir}
    ln -s %{gem_extdir}/lib/bar.so
popd
Comment 2 Vít Ondruch 2013-08-20 04:24:01 EDT
Thanks for your report.

The Ruby support for binary extensions was never designed in a way to support multiple roots, hence the binary extension path is derived from Ruby location. Unfortunately, since your gems are in different SCL root, Ruby has no clue about it. The possible solution might be to take GEM_PATH environment variable during evaluation of binary extension location.
Comment 3 Stanislav Ochotnicky 2013-08-20 07:19:23 EDT
Moving to 1.1.0
Comment 7 errata-xmlrpc 2014-06-04 03:15:50 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-0619.html

Note You need to log in before you can comment on or make changes to this bug.