Project

General

Profile

Actions

Bug #6903

closed

[[Ruby 1.9:]] --enable-load-relative broken on systems with /lib64

Added by mpapis (Michal Papis) almost 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
Backport:
[ruby-core:47267]

Description

=begin
Trying to build ruby with --enable-load-relative on system where libraries are by default stored in lib64.

This leads to this error on most ruby operations, with minimal example ruby -e 'p :a':

<internal:gem_prelude>:1:in `require': cannot load such file -- rubygems.rb (LoadError)
   	    from <internal:gem_prelude>:1:in `<compiled>'

It works when I prefix it with RUBYLIB:

RUBYLIB=/home/mpapis/.rvm/rubies/ruby-1.9.3-p194/lib64/ruby/:/home/mpapis/.rvm/rubies/ruby-1.9.3-p194/lib64/ruby/1.9.1/:/home/mpapis/.rvm/rubies/ruby-1.9.3-p194/lib64/ruby/1.9.1/x86_64-linux/ /home/mpapis/.rvm/rubies/ruby-1.9.3-p194/bin/ruby -e 'p :a'

So the lib64 path was not respected, I have prepared the attached patch and compiled using it but it did not helped.

The only thing I could use to fix it was compiling using additional configure flag:

--libdir=/home/mpapis/.rvm/rubies/ruby-1.9.3-p194/lib

so the default detected lib64 was overwritten and it all worked fine.

The check for the libdir is: gcc -print-multi-os-directory

Under this address should be a link to vagrant box for system that has lib64 as default: https://github.com/jtperry/OpenSuseVagrantBox

The best solution would be to fix loading libraries from the custom paths, but if it is not possible it would be also good enough to force libdir=.../lib if not specified by user.
=end


Files

ruby-multilib.patch (626 Bytes) ruby-multilib.patch example patch for ompilation mpapis (Michal Papis), 08/22/2012 11:16 AM
ruby-multilib.patch (899 Bytes) ruby-multilib.patch fixed initial patch for ruby-head mpapis (Michal Papis), 08/27/2012 05:07 AM
ruby-multilib.patch (832 Bytes) ruby-multilib.patch fixed initial patch for ruby-1.9.3-p194 mpapis (Michal Papis), 08/27/2012 07:52 AM

Related issues 1 (0 open1 closed)

Related to Ruby master - Bug #7172: [[Ruby 1.9:]] fix rbconfig for --enable-load-relative (v2)Closednobu (Nobuyoshi Nakada)10/16/2012Actions

Updated by nobu (Nobuyoshi Nakada) almost 10 years ago

  • Description updated (diff)
  • Category set to build
  • Status changed from Open to Feedback

Where does that lib64 in RUBYLIB come from?
And your patch seems reversed.

Updated by mpapis (Michal Papis) almost 10 years ago

=begin
lib64 is the default path for installing libraries on my system, I guess #6207 is related in this manner (other libraries also install to /lib64).

I can find all ruby libraries/code in /lib64, /lib is empty.

I also get the /lib64 when running:

gcc -print-multi-os-directory

so this setting is embedded in gcc.

as for the order - I did not payed attention to it, just tried to get it working at all.
=end

Updated by nobu (Nobuyoshi Nakada) almost 10 years ago

  • Status changed from Feedback to Third Party's Issue

Thank you, then your version of ruby is patched but not plain.
Your patch seems reverting the unofficial (and probably incomplete) modification, so it cannot merge.

Updated by mpapis (Michal Papis) almost 10 years ago

=begin
My patch does not fix it - it was only an attempt to make it working, it's not final, it did fix the rpath and compiled in paths, but it does not fix searching for libraries.

My guess is that ruby library search code still has /lib hardcoded and because of this it does not find libraries compiled in /lib64 ... all that said it happens only with --enable-load-relative. If you could point me to the code that handles library search when it is in effect I could play with it and try to prepare a full fix.

Also can you point me to to the:

unofficial (and probably incomplete) modification

=end

Updated by mpapis (Michal Papis) almost 10 years ago

=begin
found this http://gcc.gnu.org/ml/fortran/2008-09/msg00146.html - which explains that lib64 is the default behavior, it looks like most distributions change it to lib .. not sure why.

And a noob question, why is it "Third Party's Issue"?
=end

Updated by mpapis (Michal Papis) almost 10 years ago

=begin
so the new patch fixes it for ruby head, still not for 1.9.3, the only thing that I was find fast was in head:

verconf.h:2:#define RUBY_LIB_PREFIX RUBY_EXEC_PREFIX"/lib64/ruby"

=end

Updated by mpapis (Michal Papis) almost 10 years ago

and this patch worked for 1.9.3-p194

Updated by mpapis (Michal Papis) almost 10 years ago

=begin
also pull requests so it's easier to continue (hopefully):

Actions #9

Updated by nobu (Nobuyoshi Nakada) almost 10 years ago

  • Status changed from Third Party's Issue to Open
Actions #10

Updated by nobu (Nobuyoshi Nakada) almost 10 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

This issue was solved with changeset r36847.
Michal, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


configure.in: use configured libdir value

  • configure.in (LIBDIR_BASENAME): use configured libdir value to fix
    --enable-load-relative on systems where libdir is not default value,
    overridden in config.site files. [ruby-core:47267] [Bug #6903]
  • ruby.c (ruby_init_loadpath_safe): ditto.

Updated by mpapis (Michal Papis) almost 10 years ago

=begin
you might want to test your fix on OSX where

gcc -print-multi-os-directory

returns

x86_64

=end

Actions

Also available in: Atom PDF