The problem is that none of the standard install locations for ruby libraries are the same between 32 and 64 bit architectures. The following entries in Config::CONFIG should be changed: rubylibdir - '/usr/lib/ruby/RUBY_VERSION' on all arches sitelibdir - '/usr/lib/ruby/site_ruby/RUBY_VERSION' on all arches sitedir - '/usr/lib/ruby/site_ruby' on all arches archdir - /usr/lib/ruby/RUBY_VERSION/ARCH for 32bit and /usr/lib64/ruby/RUBY_VERSION/ARCH for 64bit sitearchdir - /usr/lib/ruby/site_ruby/RUBY_VERSION/ARCH for 32bit and /usr/lib64/ruby/site_ruby/RUBY_VERSION/ARCH for 64bit Also, $: probably needs to be initialized a little differently to ensure that 64bit binaries receive preference over 32bit binaries on multilib. I believe the following would be a better order: [ sitearchdir, sitelibdir, sitedir, archdir, rubylibdir, "." ]
Discussion about various ways to address this bug: https://www.redhat.com/archives/fedora-extras-list/2006-March/msg01264.html
I'm working on this and just made a testing package. can you guys test it if it works/is buildable properly for any ruby packages? Testing packages are available on http://people.redhat.com/tagoh/ruby/. TIA
(In reply to comment #0) > Also, $: probably needs to be initialized a little differently to ensure that > 64bit binaries receive preference over 32bit binaries on multilib. I believe the > following would be a better order: [ sitearchdir, sitelibdir, sitedir, archdir, > rubylibdir, "." ] I disagree. it will makes incompatible behavior between 32bit and 64bit. even if we change it for all archs, it's still incompatible between ours and upstream, and other distros too.
I've put another testing package on the same place that includes adding the deprecated path to the search path, providing ruby(abi) etc.
If there are any issues on this testing package, I'm planning to push it next Monday.
Fixed in 1.8.4-6