Bug #6903

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

Added by Michal Papis over 1 year ago. Updated over 1 year ago.

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

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

ruby-multilib.patch Magnifier - example patch for ompilation (626 Bytes) Michal Papis, 08/22/2012 11:16 AM

ruby-multilib.patch Magnifier - fixed initial patch for ruby-head (899 Bytes) Michal Papis, 08/27/2012 05:07 AM

ruby-multilib.patch Magnifier - fixed initial patch for ruby-1.9.3-p194 (832 Bytes) Michal Papis, 08/27/2012 07:52 AM


Related issues

Related to ruby-trunk - Bug #7172: [[Ruby 1.9:]] fix rbconfig for --enable-load-relative (v2) Closed 10/16/2012

Associated revisions

Revision 36847
Added by Nobuyoshi Nakada over 1 year ago

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. [Bug #6903]
  • ruby.c (rubyinitloadpath_safe): ditto.

Revision 36873
Added by Nobuyoshi Nakada over 1 year ago

configure.in: unquote

  • configure.in (LIBDIR_BASENAME): unquote shell variable. [Bug #6903]

Revision 38776
Added by Nobuyoshi Nakada over 1 year ago

mkconfig.rb: use configured libdir value

  • tool/mkconfig.rb: use configured libdir value to fix --enable-load-relative on systems where libdir is not default value, overridden in config.site files. [Bug #6903]

History

#1 Updated by Nobuyoshi Nakada over 1 year 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.

#2 Updated by Michal Papis over 1 year 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

#3 Updated by Nobuyoshi Nakada over 1 year 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.

#4 Updated by Michal Papis over 1 year 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

#5 Updated by Michal Papis over 1 year 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

#6 Updated by Michal Papis over 1 year 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

#7 Updated by Michal Papis over 1 year ago

and this patch worked for 1.9.3-p194

#8 Updated by Michal Papis over 1 year ago

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

#9 Updated by Nobuyoshi Nakada over 1 year ago

  • Status changed from Third Party's Issue to Open

#10 Updated by Nobuyoshi Nakada over 1 year 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. [Bug #6903]
  • ruby.c (rubyinitloadpath_safe): ditto.

#11 Updated by Michal Papis over 1 year ago

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

gcc -print-multi-os-directory

returns

x86_64

=end

Also available in: Atom PDF