FEATURES=multilib-strict throws up errors on ruby modules. By default ruby installs site packages in /usr/lib/ruby/site_ruby. These are mostly arch independant scripts but a few shared libs get installed into an arch dependant subdirectory /usr/lib/ruby/site_ruby/$PV/$ARCH-linux. To see this: # emerge ruby ruby-libart2 I assume this is the correct place for these libs? If so please add ruby to MULTILIB_STRICT_EXEMPT variable in ebuild.sh.
This is the wrong place. They should go into /usr/lib64/site_ruby/${PV}/${ARCH}, as on pure 64bit systems there might be no /usr/lib diectory.
Well if that's the case then we need to look at pretty much anything that installs a perl module since perl does exactly the same thing (and does not result in multilib-strict errors since /usr/lib/perl is in MULTILIB_STRICT_EXEMPT)
I don't know why perl should be an exemption to normal policy... ruby definitely is none anymore thanks to a one line patch to the ebuild: [econf] --with-sitedir=\$\(prefix\)/$(get_libdir)/ruby/site_ruby did it. FIXED as of dev-lang/ruby-1.8.2-r1
I'm not sure, but it looks like what was done here broke all packages that use ruby gems. Try running 'gem' with either ruby-1.8.2-r1 or 1.8.3 pre1 and you get: /usr/bin/gem:3:in `require': No such file to load -- rubygems (LoadError) from /usr/bin/gem:3
This fix breaks installation of packages that use the standard 'setup.rb' packaging mechanism. The default behavior of setup.rb is to install the package files under /usr/lib/ruby/site_ruby/1.8. Ruby fails to search there, however, and does not find the files. Note that this problem has nothing to do with shared objects. The files in question in this case are pure Ruby.
*** Bug 97536 has been marked as a duplicate of this bug. ***
I'll take the patch out of ruby for the time being. What bothers me is: /usr/lib is a symlink to /usr/lib64, so ruby _should_ find all the files.
I'm on x86. I only ended up here trying to find out who broke ruby :-(. Here are the relevant lines from 'strace irb -r redcloth'. stat64("/lib/ruby/site_ruby/1.8/redcloth.rb", 0xbfffb860) = -1 ENOENT (No such file or directory) stat64("/lib/ruby/site_ruby/1.8/i686-linux/redcloth.rb", 0xbfffb860) = -1 ENOENT (No such file or directory) stat64("/lib/ruby/site_ruby/redcloth.rb", 0xbfffb860) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/1.8/redcloth.rb", 0xbfffb860) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/1.8/i686-linux/redcloth.rb", 0xbfffb860) = -1 ENOENT (No such file or directory) stat64("./redcloth.rb", 0xbfffb860) = -1 ENOENT (No such file or directory) write(2, "No such file to load -- redcloth"..., 35No such file to load -- redcloth.rb) = 35 redcloth.rb is installed in its standard location of /usr/lib/ruby/site_ruby/1.8. (Note that setup.rb does not install things in /usr/lib/... by default. It determines where to install things by asking ruby about its autoconfig parameters. That just happens to be /usr/lib on most platforms.) Ruby's convention for .so's is well-established, and it works. I recommend leaving it alone. Even if you can get it to work, it will change a familiar convention without any obvious benefit.
(In reply to comment #8) > I'll take the patch out of ruby for the time being. > > What bothers me is: /usr/lib is a symlink to /usr/lib64, so ruby _should_ > find all the files. here is an interesting thing ... ruby's pathing is all messed up .. # ruby -e "puts $:.inspect" ["/lib64/ruby/site_ruby/1.8", "/lib64/ruby/site_ruby/1.8/x86_64-linux", "/lib64/ruby/site_ruby", "/usr/lib64/ruby/1.8", "/usr/lib64/ruby/1.8/x86_64-linux", "."] nowhere in this list is the "default" location ruby packages want to install themselves to which is: /usr/lib(64?)/ruby/1.8/site_ruby/1.8 (which is where rubygems among other things install themselves to) # qpkg -l rubygems dev-ruby/rubygems-0.8.10 * CONTENTS: /usr /usr/bin /usr/bin/gemwhich /usr/bin/gem /usr/bin/gem_server /usr/bin/generate_yaml_index.rb /usr/bin/update_rubygems /usr/lib64 /usr/lib64/ruby /usr/lib64/ruby/site_ruby /usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8/ubygems.rb /usr/lib64/ruby/site_ruby/1.8/rubygems.rb /usr/lib64/ruby/site_ruby/1.8/gemconfigure.rb /usr/lib64/ruby/site_ruby/1.8/rubygems /usr/lib64/ruby/site_ruby/1.8/rubygems/specification.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/builder.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/command.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/config_file.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/doc_manager.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/format.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/cmd_manager.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/gem_runner.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/installer.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/loadpath_manager.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/old_format.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/open-uri.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/package.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/remote_installer.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/rubygems_version.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/source_index.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/deployment.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/timer.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/user_interaction.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/validator.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/version.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/gem_commands.rb /usr/lib64/ruby/site_ruby/1.8/rubygems/dependency_list.rb /usr/lib /usr/lib/ruby /usr/lib/ruby/gems /usr/lib/ruby/gems/1.8 /usr/lib/ruby/gems/1.8/cache /usr/lib/ruby/gems/1.8/cache/sources-0.0.1.gem /usr/lib/ruby/gems/1.8/doc /usr/lib/ruby/gems/1.8/doc/.keep /usr/lib/ruby/gems/1.8/gems /usr/lib/ruby/gems/1.8/gems/sources-0.0.1 /usr/lib/ruby/gems/1.8/gems/sources-0.0.1/lib /usr/lib/ruby/gems/1.8/gems/sources-0.0.1/lib/sources.rb /usr/lib/ruby/gems/1.8/specifications /usr/lib/ruby/gems/1.8/specifications/sources-0.0.1.gemspec /usr/share /usr/share/doc /usr/share/doc/rubygems-0.8.10 /usr/share/doc/rubygems-0.8.10/html /usr/share/doc/rubygems-0.8.10/html/doc.css /usr/share/doc/rubygems-0.8.10/examples /usr/share/doc/rubygems-0.8.10/examples/application /usr/share/doc/rubygems-0.8.10/examples/application/bin /usr/share/doc/rubygems-0.8.10/examples/application/bin/myapp /usr/share/doc/rubygems-0.8.10/examples/application/lib /usr/share/doc/rubygems-0.8.10/examples/application/lib/somefunctionality.rb /usr/share/doc/rubygems-0.8.10/examples/application/an-app.gemspec /usr/share/doc/rubygems-0.8.10/ChangeLog.gz /usr/share/doc/rubygems-0.8.10/README.gz /usr/share/doc/rubygems-0.8.10/TODO.gz
[econf] --with-sitedir=\$\(prefix\)/$(get_libdir)/ruby/site_ruby this is the problem, the broken one. $(prefix) is not what you want. First because it calls the "prefix" command that does not exists. Second because econf is then expanded. Third because we just install in /usr right now (when we'll support alternative prefixes, there will be a way to handle that, too). A working fix would be just adding it with /usr instead of $(prefix) .. running "gem" doesn't seem to break, the path are rights, and a gem-installed rbot installed in the right place.. Rob, is that enough for you? :)
Ping ruby herd again.
I'm here, but I'm not a lib64 guy so one of you 64 bit arches should fix the issue.
I have the solution (see comment #12), just want to know if it might create problems for you if --with-sitedir=/usr/lib on x86... Worse can't go on amd64, at maximum it won't work on development experimental profiles so we can get rid of the problems before they get into mainline.
*** Bug 112236 has been marked as a duplicate of this bug. ***
*** Bug 114638 has been marked as a duplicate of this bug. ***
Okay fixed, also if it's just a partial fix: now all the ruby extensions are installed in /usr/lib64 (exactly as it would have been if Danny's fix worked), instead of installing in /usr/lib the ones that are arch-independent. I tried finding a more complete solution, but it involves tinkering with config.h and the makefile re-runs configure after econf, and that breaks my idea. Also, if we share the arch-independent directory we have problems with collision when two arch-dependent packages shares some .rb files (see qtruby). There's still the problem that qtruby and korundum installs in /usr/lib(64) instead of /usr/kde . A more complete solution would involve changes in ruby's buildsystem and I'd rather not touch that yet.
