Unable to install versions of Ruby with rbenv (build failure)

Development
1

Requirements

I have Searched the forum for my issue and found nothing related or helpful
I have checked the Resources category (Resources Index)
I have reviewed the Wiki for relevant information
I have read the the Release Notes and Errata

OpenMandriva Lx version

OpenMandriva Lx release 6.0 (Vanadium) Rock for x86_64

Desktop environment (KDE, LXQT…)

Hyprland

Description of the issue (screenshots if relevant):

Installing rbenv

I am attempting to download/manage versions of Ruby using rbenv. If you go to rbenv.org and look at the installation instructions for a distro-agnostic install it directs you to install like so:

Installation

To install rbenv and ruby-build on a system with either Homebrew or git, paste this into your terminal:

curl -fsSL https://rbenv.org/install.sh | bash

Executing the above (which I’ve later figured out is the rbenv-installer seems to work, and I can execute commands using it.

☒ Installing a specific version of Ruby

  1. I decide to install Ruby 3.2.0, because that is what is recommended for my project requirements. To do this with rbenv, I command the execute the following:
rbenv install rbx-4.20

  1. My initial log reads that the BUILD FAILED (OpenMandriva Lx 6.0 on x86_64 using ruby-build 20251008) [1].

  2. I notice at the bottom of the output: See the full build log at /tmp/ruby-build.20251009172817.4213.log, so I check the contents of the log [2] with:

less /tmp/ruby-build.20251009172817.4213.log

And scroll to the bottom.

Installing build-essentials in an attempt to rectify the issue

  1. Due to things like string.h being missing, I make an ignorant assumption (I don’t have much experience with C nor building software from source) that I need some build essentials. I look up “build essentials” in the OMLx forums (i.e., this website) and find the Developer Tools (build-essential equivalent) thread, and make the determination to install build-essentials.

  2. After installing build-essentials, I recieve another build failure with the exact content of the first build failure in my shell [1]. I check the contents of /tmp/ruby-build.20251009175855.6328.log with:

less /tmp/ruby-build.20251009175855.6328.log

And I’m now at a loss.
My guess is that the key to solving the issue would be in the last few lines of the output, which mentions things like linux-gnu-ld.bfd: final link failed: bad value [3]. However, I lack expertise in this department.

Relevant information (hardware involved, software version, logs or output…)

The following section is going to contain the content of my references during my Description of the issue, there will be citation numbers that will correspond to the ordered list here.

  1. Build failure on OMLx ROCK 6.0:
wolfdaemon@sigma:~$ rbenv install rbx-4.20
==> Downloading openssl-1.0.2u.tar.gz...
-> aria2c --allow-overwrite=true --no-conf=true --console-log-level=warn --stderr -o openssl-1.0.2u.tar.gz https://www.openssl.org/source/openssl-1.0.2u.tar.gz

Download Results:
gid   |stat|avg speed  |path/URI
======+====+===========+=======================================================
29d72d|OK  |    19MiB/s|/tmp/ruby-build.20251009172817.4213.hrWjQ5/openssl-1.0.2u.tar.gz

Status Legend:
(OK):download completed.
==> Installing openssl-1.0.2u...
-> ./config "--prefix=$HOME/.rbenv/versions/rbx-4.20/openssl" "--openssldir=$HOME/.rbenv/versions/rbx-4.20/openssl/ssl" --libdir=lib zlib-dynamic no-ssl3 shared "-Wl,-rpath,$HOME/.rbenv/versions/rbx-4.20/openssl/lib" no-ssl2 no-krb5
-> make -j 12

BUILD FAILED (OpenMandriva Lx 6.0 on x86_64 using ruby-build 20251008)

You can inspect the build directory at /tmp/ruby-build.20251009172817.4213.hrWjQ5
See the full build log at /tmp/ruby-build.20251009172817.4213.log
  1. Contents of the initial build log /tmp/ruby-build.20251009172817.4213.log. Because there are too many lines for me to copy, I will include the entire log file as an attachment to this post
    ruby-build.20251009172817.4213.txt (29 KB):
...
../include/openssl/crypto.h:120:11: fatal error: stdlib.h: No such file or directory
  120 | # include <stdlib.h>
      |           ^~~~~~~~~~
compilation terminated.
make[1]: *** [<builtin>: mem.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [<builtin>: cryptlib.o] Error 1
make[1]: *** [<builtin>: mem_dbg.o] Error 1
make[1]: *** [<builtin>: ex_data.o] Error 1
make[1]: *** [<builtin>: cpt_err.o] Error 1
make[1]: *** [<builtin>: uid.o] Error 1
make[1]: *** [<builtin>: o_str.o] Error 1
make[1]: *** [<builtin>: o_dir.o] Error 1
make[1]: *** [<builtin>: o_fips.o] Error 1
make[1]: *** [<builtin>: o_time.o] Error 1
make[1]: *** [<builtin>: o_init.o] Error 1
make[1]: Leaving directory '/tmp/ruby-build.20251009172817.4213.hrWjQ5/openssl-1.0.2u/crypto'
make: *** [Makefile:287: build_crypto] Error 1
external command failed with status 2
  1. Contents of the build log after installing build-essentials. Because there are too many lines for me to copy, I will include the entire log file as an attachment to this post as well
    ruby-build.20251009175855.6328.txt. (321.5 KB):
...
/usr/bin/x86_64-openmandriva-linux-gnu-ld.bfd: libcrypto.a(ecp_nistz256-x86_64.o): warning: relocation against `OPENSSL_ia32cap_P' in read-only section `.text'
/usr/bin/x86_64-openmandriva-linux-gnu-ld.bfd: libcrypto.a(sha1-x86_64.o): relocation R_X86_64_PC32 against undefined symbol `OPENSSL_ia32cap_P' can not be used when making a shared object; recompile with -fPIC
/usr/bin/x86_64-openmandriva-linux-gnu-ld.bfd: final link failed: bad value
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile.shared:169: link_a.gnu] Error 1
make[4]: Leaving directory '/tmp/ruby-build.20251009175855.6328.EbVUs0/openssl-1.0.2u'
make[3]: *** [Makefile:357: do_linux-shared] Error 2
make[3]: Leaving directory '/tmp/ruby-build.20251009175855.6328.EbVUs0/openssl-1.0.2u'
make[2]: *** [Makefile:310: libcrypto.so.1.0.0] Error 2
make[2]: Leaving directory '/tmp/ruby-build.20251009175855.6328.EbVUs0/openssl-1.0.2u'
make[1]: *** [Makefile:111: shared] Error 2
make[1]: Leaving directory '/tmp/ruby-build.20251009175855.6328.EbVUs0/openssl-1.0.2u/crypto'
make: *** [Makefile:287: build_crypto] Error 1
external command failed with status 2
2

Let’s back up for a second and talk about the goal of this. I would guess it’s a requirement of something that is either in flatpak or appimage and you don’t want to use those, or some other software we don’t package.

It’s downloading openssl, which we already package. That seems counterproductive.

Definitely, since this is all supposed to be supplied by the openssl it was supposed to download.

Honestly, you will probably need to wait for someone more familiar with Ruby to help you. It should also be set up as a package instead of this.

ls -la /usr/include/string.h
-rw-r--r-- 1 root root 19969 Jul 30 08:31 /usr/include/string.h

dnf provides /usr/include/string.h
Updating and loading repositories:
Repositories loaded.
glibc-devel-6:2.42-1.x86_64 : Header and object files for development using standard C libraries
Repo         : @System
Matched From :
Filename     : /usr/include/string.h

glibc-devel-6:2.42-1.x86_64 : Header and object files for development using standard C libraries
Repo         : cooker-x86_64
Matched From :
Filename     : /usr/include/string.h
4

So, the solution was to install rbenv using homebrew, right?

I can confirm that trying to install any version of ruby using rbenv fails with different ‘BUILD FAILURE’ messages. This is the rbenv installed using the script from rbenv.org site. However, if we install rbenv using homebrewas shown above, we are able to install any desired version of ruby, without issues. That is probably because, it automatically installs required dependencies.

That said, I was able to install ruby using rbenv installed via the script. It needed several dependencies to be installed in order to build properly. For me, build failed first for missing Time/Piece.pm, then for missing zlib.h, ext/ffi, ext/psych etc. I had to install following packages. These are regular ‘dnf’ installs.

  • perl-Time-Piece (for me installing Time::Piece module via `perl -MCPAN -e module Time::Piece` did not work. rbenv always failed to see the module)
  • perl-CPAN-Meta
  • perl-CPAN-Meta-Requirements
  • lib64z-devel (for missing zlib.h)
  • lib64ffi-devel (for missing ffi)
  • lib64yaml-devel (for missing ext/psych

So yes, homebrew method is better. And, we get to use brew, which seems quite powerful.

1 Like
5

Thanks @sigvirt, this satisfies me more.

Question, how did you get rbenv to actually set the global Ruby? For whatever reason, my system isn’t able to get the global Ruby to the one rbenv installed, i.e.:

which ruby outputs the system version:

/usr/bin/ruby

ruby -v outputs the system version:

ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux-gnu]

I can’t seem to get the system to actually set Ruby to the version I installed globally (mine being 3.2.0).

6

Manual install is an actual solution for OpenMandriva Lx, NOT Homebrew

@sigvirt, I will also probably highlight your post the actual solution because the Homebrew method has a flaw: the Module or Group 'development tools' is not available. development-tools is a requirement/dependency that Homebrew needs to work properly that OpenMandriva Lx does not have; I’ve deleted my original “solution” so as not to mislead people with misinformation.

development-tools not available as a Homebrew dependency

Upon the installation of Homebrew, one of the various steps the output instructs you to do in the Next steps section to actually set up Homebrew on Linux is to:

Install Homebrew's dependencies if you have sudo access:
    sudo dnf group install development-tools

The output for the various methods of attempting to install development-tools on OMLx

Except, OpenMandriva Lx does NOT have development-tools, hence:

sudo dnf group install development-tools
[sudo] password for $USER: 
download.vscodium.com                                                   25 kB/s | 3.0 kB     00:00    
download.vscodium.com                                                  8.5 kB/s | 1.8 kB     00:00    
Module or Group 'development-tools' is not available.

Or alternatively:

sudo dnf groupinstall "Development Tools"
Last metadata expiration check: 0:01:50 ago on Fri 10 Oct 2025 02:40:36 PM CDT.
Module or Group 'Development Tools' is not available.
Error: Nothing to do.
7

I’m confused. If you go to rbenv’s GitHub page, it clearly says the Homebrew instructions are for MacOS (Homebrew is a package manager for MacOS). For OpenMandriva, you should use the manual install instructions and/or submit a package request:

Or is there something else I’m missing?

8

Yeah; I had rbenv installed in about two minutes with this procedure:

  1. sudo dnf install ruby

  2. From my home dir, git clone https://github.com/rbenv/rbenv ~/.rbenv

  3. Edit your .bashrc or .profile and add the rbenv binary to your path:

    ```bash
    export PATH=$PATH:~/jpm/bin:~/.npm-global/bin:/usr/local/texlive/2025/bin/x86_64-linux:~/.rbenv/bin
    ```

  4. (sorry for the extra entries here; that’s a literal copy/paste from my .profile. I have a manually installed Texlive and some other stuff I need for work. The rbenv entry is the last one)

  5. Put rbenv init somewhere in your .bashrc or .profile according to the instructions on GitHub.

I think that’ll do it.

9

No, it’s a solution for you. The solution for OpenMandriva Lx, is to make a package that could be supported for everyone.

10

Inconsistent behavior with initializing the rbenv binary on both rbenv’s Basic Git Checkout & rbenv-installer installation script

Okay, so I’ve noticed the source of the weird, inconsistent behavior that is exemplified by the rbenv’s Basic Git Checkout’s initialization command’s output and rbenv-installer initialization script. Both will produce either of the outputs, depending on a certain circumstance that I’m not certain of:

  1. This value version of the output of the init is the working one.
    ## Added by `rbenv init` on Fri Oct 10 05:08:38 PM CDT 2025
eval "$(~/.rbenv/bin/rbenv init - --no-rehash bash)":
  2. This is another version of the output of the init command that results in rbenv: command not found in the shell:
    ## Added by `rbenv init` on Fri Oct 10 04:49:12 PM CDT 2025
eval "$(rbenv init - --no-rehash bash)"

Upon installing rbenv with rbenv’s Basic Git Checkout and rbenv-installer’s initialization script, repeatedly wiping the entries within ~/.bashrc & deleting ~/.rbenv after, and comparing the differences of output between the two, this appears to be the difference that breaks rbenv within OpenMandriva Lx.

The possible common denominator for the two different values of output for intializing the rbenv binary could be that the order of instructions provided by the upstream repostitory is out-of-order

I believe that the common denominator is this:

The instructions rbenv’s Basic Git Checkout section instructs the user to first:

  1. Set up your shell to load rbenv.
~/.rbenv/bin/rbenv init

And then restart your shell:

  1. Restart your shell so that these changes take effect.

However, I’ve noticed that I’ve been able to consistently get the working value of the PATH (reposted below, mentioned in first section):

## Added by `rbenv init` on Fri Oct 10 05:08:38 PM CDT 2025
eval "$(~/.rbenv/bin/rbenv init - --no-rehash bash)":

How to resolve the output mismatch of rbenv’s init command

HOWEVER, if I switch the instructions around from rbenv’s Basic Git Checkout section, and do:

  1. “3. Restart your shell so that these changes take effect. (Opening a new terminal tab will usually do it.)” first, and then
  2. “2. Set up your shell to load rbenv” afterwards.

THEN, I get desirable working value of the path within ~/.bashrc posted above consistently, using at least using the rbenv’s Basic Git Checkout method. As for the rbenv-installer initialization script, it seems to be hit-or-miss as to whether it produces the right output.

11

No, it’s a solution for you. The solution for OpenMandriva Lx, is to make a package that could be supported for everyone.

This is a statement based on semantics. It is obvious in the contents of my post, that what I mean by “actual solution for OpenMandriva Lx” is that using @sigvirt’s method of installation is a solution that has all of the dependencies handled, and is the least likely to carry unintended consequences if someone were to install versions of Ruby on OpenMandriva Lx. I.e., it’s a solution… that actually works, without “spare” screws loose figuratively on the garage floor, unlike attempting to use Homebrew.

As to whether that’s a convenient solution, and whether OpenMandriva Lx as a distribution should provide a package that automatically manages this, is another subject. I think if anything, the evidence suggests that this is could be an upstream problem: so a bug/issue report to be filed on the behalf of OMLx users (and possibly other distro’s, given the scenario).

12

I’m just saying. Writing the spec and the patch you suggest would have taken less work than 2-3 forum threads and two threads in two different chat rooms.

1 Like
13

I agree!

14

Cool. Get to it.

15

I will if I want to, when I want to, and when I have the time to.

Thank you!

16

Until then, please keep the conversation here instead of multiple threads and multiple places. We are trying to get UM done.

Thanks.

17

When I need support, I will talk about it in the support forum and the support chats. That’s what the support forum/chats are for.

Thanks!

18

We are not supporting your manual install of something we don’t package.

Thanks!

19

Are you suggesting I make a package request? Like, what is the overall point/goal of your comments on this thread, exactly?

20

I’m suggesting that instead of wasting our time and spamming our comms with things we don’t support, that you should make the package and submit it for review. Then our time can be used constructively to help more than just you with this issue.

21

@zeroability , you have my explicit permission to not respond to my threads on this forum and messages on Element. If you think my activity here on the forums and on the chat is “spamming”, then you’re off the hook, mate. I don’t want your support on this issue. Thank you for your time.

I’m taking the time to document my issue on the forum posts so as to help future OMLx users who might encounter this problem as I have, so that they can find the help they need in the future. My only recent messages on Element were to ask valid questions regarding:

  1. Why my response on an open support thread was closed due to “necroposting”, even though the content of that exact thread is still relevant.
  2. About the packages that OpenMandriva Lx does package (dependencies for building software on OMLx) that is related to this topic.
  3. To follow up with pings with my username surrounding this issue (meaning I myself didn’t initiate or “spam” those messages).

If you feel so adamant that I am “spamming” and that my behavior on the forum is somehow inappropriate, talk about it with a moderator. This is off-topic for this thread.