You are not logged in.
I have a 32-bit server that I'm using Ruby on and don't touch very often. I think it was originally an Arch install and now an Arch32 after 32-bit support was deprecated. Recently, I started getting this exception:
$ irb
irb(main):001:0> require "date_core"
<internal:/usr/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- date_core (LoadError)
from <internal:/usr/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
from (irb):1:in `<main>'
from /usr/lib/ruby/gems/3.0.0/gems/irb-1.4.2/exe/irb:11:in `<top (required)>'
from /usr/bin/irb:25:in `load'
from /usr/bin/irb:25:in `<main>' I suspect this happened when I updated some ruby packages, including ruby-date
[ALPM] upgraded rubygems (3.3.23-1.5 -> 3.3.25-1.0)
[ALPM] upgraded ruby-abbrev (0.1.0-3.9 -> 0.1.0-4.0)
[ALPM] upgraded ruby-base64 (0.1.1-3.9 -> 0.1.1-4.0)
[ALPM] upgraded ruby-benchmark (0.2.0-3.8 -> 0.2.0-4.0)
[ALPM] upgraded ruby-bigdecimal (3.1.2-3.6 -> 3.1.2-4.0)
[ALPM] upgraded ruby-bundler (2.3.23-1.4 -> 2.3.25-1.0)
[ALPM] upgraded ruby-cgi (0.3.3-1.4 -> 0.3.6-1.0)
[ALPM] upgraded ruby-date (3.2.2-3.6 -> 3.2.2-4.0)
[ALPM] upgraded ruby-stdlib (3.0.4-18.8 -> 3.0.4-20.0)
[ALPM] upgraded ruby-bundledgems (3.0.4-18.8 -> 3.0.4-20.0)
[ALPM] upgraded ruby (3.0.4-18.8 -> 3.0.4-20.0)
[ALPM] upgraded ruby-webrick (1.7.0-1.0 -> 1.8.1-1.0)I can work around this with
export RUBYLIB=/usr/lib/ruby/3.0.0/x86-linux/but it's weird and I shouldn't have to work around it. I eventually tracked it down to date_core.so being in /usr/lib/ruby/3.0.0/x86-linux/ which was not on Ruby's path.
$ ruby -e 'puts $LOAD_PATH'
/usr/lib/ruby/site_ruby/3.0.0
/usr/lib/ruby/site_ruby/3.0.0/i686-linux
/usr/lib/ruby/site_ruby
/usr/lib/ruby/vendor_ruby/3.0.0
/usr/lib/ruby/vendor_ruby/3.0.0/i686-linux
/usr/lib/ruby/vendor_ruby
/usr/lib/ruby/3.0.0
/usr/lib/ruby/3.0.0/i686-linux
$ ls /usr/lib/ruby/3.0.0/x86-linux/date_core.so
/usr/lib/ruby/3.0.0/x86-linux/date_core.soWhat was strange to me is that 32-bit .so files are in two subdirectories, i686 and x86-linux.
$ ls /usr/lib/ruby/3.0.0/x86-linux/
bigdecimal.so cgi date_core.so
$ ls /usr/lib/ruby/3.0.0/i686-linux/
continuation.so dbm.so digest.so etc.so fiber.so gdbm.so json nkf.so openssl.so psych.so racc rbconfig.rb ripper.so stringio.so syslog.so
coverage.so digest enc fcntl.so fiddle.so io monitor.so objspace.so pathname.so pty.so rbconfig readline.so socket.so strscan.so zlib.soI found two packages that owned files in the two directories
$ yay -Qo /usr/lib/ruby/3.0.0/x86-linux/date_core.so /usr/lib/ruby/3.0.0/i686-linux/digest.so
/usr/lib/ruby/3.0.0/x86-linux/date_core.so is owned by ruby-date 3.2.2-4.0
/usr/lib/ruby/3.0.0/i686-linux/digest.so is owned by ruby-digest 3.1.0-5.8If I'm understanding the build files correctly, both ruby-date and ruby-digest use gem env platform | cut -d':' -f2 to generate the subdirectory, but they're producing different results.
I also noticed that that some of the Ruby packages are marked for deletion, like ruby-date and ruby-digest
Questions:
a) any idea why this happens? Is it an artifact of the machine they're built on?
b) any idea how to fix it? Having a random collection of ruby packages segfault is not great. Where should I file a bug?
c) how/where is the Ruby $LOAD_PATH default set?
d) why are the Ruby packages marked for deletion? Where could I look to figure this out myself?
Offline
Knowing little to nothing about ruby, but guessing from other languages with modules: there is a mismatch of versions (interpreter and module versions don't fit).
Last time I had a look the rubyverse was neither sane nor rebuilding properly.
Currently rebuilding is a huge problem..
Offline