Separate RUBY_PREFIX_PATH and RUBY_MAKE_INSTALL_OPTS="DESTDIR" paths don't work in Ruby 2

[cspicer]

Hello!

This might not necessarily be an implementation bug but rather a change in which envvars are parsed and where in Ruby 1.9.3 vs Ruby 2. I'm experiencing the same issue described in this comment of #493.

The following options work for Ruby 1.9.3:

env YAML_CONFIGURE_OPTS="--enable-static --disable-shared --with-pic" \
RUBY_CONFIGURE_OPTS="--disable-install-doc" \
RUBY_MAKE_INSTALL_OPTS="DESTDIR=/tmp/ruby-build-1.9.3" \
RUBY_PREFIX_PATH="/usr/lib/ruby/1.9.3-p484" \
ruby-build --verbose 2.1.5 /tmp/ruby-build-1.9.3

but this fails under 2.1.5:

env YAML_CONFIGURE_OPTS="--enable-static --disable-shared --with-pic" \
RUBY_CONFIGURE_OPTS="--disable-install-doc" \
RUBY_MAKE_INSTALL_OPTS="DESTDIR=/tmp/ruby-build-2.1.5" \
RUBY_PREFIX_PATH="/usr/lib/ruby/2.1.5" \
ruby-build --verbose 2.1.5 /tmp/ruby-build-2.1.5

with this error:

installing default gems:      /usr/lib/ruby/2.1.5/lib/ruby/gems/2.1.0 (build_info, cache, doc, extensions, gems, specifications)
                              bigdecimal 1.2.4
                              io-console 0.4.2
                              json 1.8.1
                              minitest 4.7.5
                              psych 2.0.5
                              rake 10.1.0
                              rdoc 4.1.0
                              test-unit 2.1.5.0
/usr/local/bin/ruby-build: line 878: /tmp/ruby-build-2.1.5/bin/ruby: No such file or directory

BUILD FAILED (Ubuntu 12.04 using ruby-build 20141222)

Inspect or clean up the working tree at /tmp/ruby-build.20141224005327.32703
Results logged to /tmp/ruby-build.20141224005327.32703.log

Last 10 log lines:
installing default gems:      /usr/lib/ruby/2.1.5/lib/ruby/gems/2.1.0 (build_info, cache, doc, extensions, gems, specifications)
                              bigdecimal 1.2.4
                              io-console 0.4.2
                              json 1.8.1
                              minitest 4.7.5
                              psych 2.0.5
                              rake 10.1.0
                              rdoc 4.1.0
                              test-unit 2.1.5.0
/usr/local/bin/ruby-build: line 878: /tmp/ruby-build-2.1.5/bin/ruby: No such file or directory

Again, this probably isn't a bug in ruby-build but is an issue I'm running into trying to generate a Ruby install that can be packaged using fpm. Any insights would be greatly appreciated!

[mislav]

I have never done this, so I don't know what goes wrong where. Maybe a Ruby you're trying to package up shouldn't come with default gems, because some of those contain native extensions that might not support moving to a different directory.

Anyway, since this is most likely an issue with Ruby itself, you should better take it with the Ruby core team and let us know how it went.

[cspicer]

Thanks for the response!

So, I did some more digging today and I am fairly sure this is actually a ruby-build issue surrounding the verify_openssl post-build step. Using a custom definition based on the one for Ruby 2.1.5 but removing verify_openssl, the build completes successfully. I also manually verified that openssl support was working:

irb(main):001:0> require "openssl"
=> true

As far as I can tell, there are two issues at play here. First off, RUBY_BIN isn't being set correctly and still tries to use the default output path. I tried making this change:

RUBY_BIN="${RUBY_BIN:-${PREFIX_PATH}/bin/ruby}"

then trying to force it to use the path to ruby:

RUBY_BIN="/tmp/ruby-build-$VERSION/usr/lib/ruby/$VERSION/bin/ruby"

and that got me past the initial step but failed here:

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

So, I'm not sure where to go from there, but it does look like the issue is with ruby-build after all. For now I can work around the problem by using a custom definition without the verify_openssl step.

Thanks again for responding so quickly initially, and happy holidays!

[mislav]

Hmm you might be on to something here. verify_openssl relies on PREFIX_PATH, but Ruby will be physically installed into /tmp/ruby-build-2.1.5/bin/ruby right?

[bcg62]

Im also seeing this issue, anyone found a way around it?

[oshmyrko]

@bcg62, as a workaround you can remove verify_openssl check from ruby definition that you want to install and then execute ruby-build command. Definitions are located in share/ruby-build, example for Ruby 2.4.2.

MAKE_INSTALL_OPTS='DESTDIR=/tmp/fpm' \
RUBY_CONFIGURE_OPTS='--enable-shared' \
ruby-build 2.4.2 /usr/local

The build is finished successfully.

---

Also, I was trying to update RUBY_BIN in ruby-build script to this one:

RUBY_BIN="${RUBY_PREFIX_PATH:-$PREFIX_PATH}/bin/ruby"

but it fails with:

/tmp/fpm/usr/local/bin/ruby: error while loading shared libraries: libruby.so.2.4: cannot open shared object file: No such file or directory

MAKE_INSTALL_OPTS='DESTDIR=/tmp/fpm' \
RUBY_CONFIGURE_OPTS='--disable-install-doc' \
RUBY_PREFIX_PATH='/tmp/fpm/usr/local' \
ruby-build 2.4.3 /usr/local

[sschuberth]

I'm sorry to hijack this old issue, but as a quick search did not get me any results, could someone briefly explain to me what different purposes of RUBY_MAKE_INSTALL_OPTS="DESTDIR=..." vs RUBY_PREFIX_PATH=... are? In particular, which of the two can I use to not (necessarily) change what make install installs binaries to, but change the shebang lines for the scripts to a path I'm going to copy the binaries to?

[sschuberth]

Ok, from reading around I suspect that RUBY_PREFIX_PATH=... gets passed as configure --prefix=... and denotes the path where the binaries should expect to be finally installed, whereas RUBY_MAKE_INSTALL_OPTS="DESTDIR=..." can be used to first install elsewhere, from where binaries could get packaged for distribution. The package would the install to RUBY_PREFIX_PATH=... on the user's system.

[sschuberth]

a quick search did not get me any results

Maybe RUBY_PREFIX_PATH could be added to https://github.com/rbenv/ruby-build?tab=readme-ov-file#custom-build-configuration as well?

[mislav]

as a workaround you can remove verify_openssl check from ruby definition that you want to install and then execute ruby-build command

Just adding a note here that since this issue last got updated (many years ago), ruby-build changed its verify_openssl approach so it does not cause problems in combination with DESTDIR anymore. #2296

@sschuberth Your guess as to how RUBY_PREFIX_PATH can be used in combination with RUBY_MAKE_INSTALL_OPTS="DESTDIR=..." is correct, at least in theory. I have not prepared Ruby for packaging myself, but that is how it's supposed to work. However, I'm reluctant to add this to official ruby-build documentation. I do not believe that ruby-build should be an intermediary in packaging Ruby. I think that whoever is packaging Ruby should be downloading Ruby directly from official sources, verifying checksums, and passing environment variables and build configuration explicitly so that they have complete control and oversight over the packaging process, rather than invoke ruby-build that does certain things by "magic" (such as automatically downloading and compiling OpenSSL if missing). Does that make sense?

[sschuberth]

Does that make sense?

I'd say it depends 😉 If by "packing" something "serious" like packaging for a Linux distribution is meant, then you're probably right. But I'm coming from here, so packaging refers to something I only do for my own Docker images.

Independently of that, I don't really see why RUBY_PREFIX_PATH should not be documented if all (?) the other environment variables are.

[mislav]

But I'm coming from here, so packaging refer to something I only do for my own Docker images.

Thanks for sharing your use-case. I'm not familiar with mise, and frankly I do not understand what's being talked about in the thread (and at which level of that is ruby-build is involved?), but if you could try out the packaging approach using these environment variables and if that works for you, I'm open to adding a documentation blurb about this.

Please open a new issue for the documentation task, as well as more information about how this is to be used in combination with Docker. Thanks!