Older Rubies (2.1 to 2.3 at least) don't install on default macOS image (10.13.6)

[aried3r]

I've described this issue here but will post it here as well since I believe it belongs here as well. Feel free to close this issue if this is not the place. I'm not sure if it's a Travis CI issue or if I should open an issue in the rvm repo.

It seems a new OpenSSL version was released on Homebrew (1.1, from 1.0 (this also contains a successful and a failed test run)) and also the macOS build image on Travis changed since the last test run of jaro_winkler (check also the available Rubies etc).
That seems to be the cause for the failures.
Somebody posted a possible workaround to get an older OpenSSL version installed via homebrew.

Further reading:
https://travis-ci.community/t/rvm-install-fails-on-osx-due-to-missing-libraries/5596
rvm/rvm#4819
rvm/rvm#4781
rvm/rvm#4463
Homebrew/homebrew-core#46454

[BanzaiMan]

I am not sure if we can reliably support Rubies <= 2.3.x on macOS at this point.

The problem is quite complicated:

1. Rubies before 2.4.0 do not compile with OpenSSL 1.1, thus we need OpenSSL 1.0.x, which is no longer supported.
2. Homebrew, our package manager on macOS, has dropped support for OpenSSL 1.0.x, justifiably.
3. This means that we have to rely on a third-party tool (or create our own) to provide OpenSSL 1.0.x. It is possible to compile OpenSSL 1.0.x on the fly, but it will take quite some time to do so. I have not found any binary package to sidestep this issue (let alone a trustworthy one that we can use long term).
4. RVM currently is not aware of this issue, so it appears to prefer the latest OpenSSL version when we ask for Ruby < 2.4.0.
5. The problem would be mitigated if we could compile a static macOS binary that can be ported across machines, but as far as I know, currently there is no way to do so.

It is conceivably possible to:

1. Compile OpenSSL 1.0 (this is not difficult)
2. Coerce RVM to compile Ruby with this OpenSSL instead of the latest version
3. Package all the binary files into the archive, so that users don't have to compile things at build time.
4. ???
5. $$ Profit $$

[hurricup]

As I mentioned in my mail to support, there are at least two ways to do so:

# using rvm pkg install (deprecated)
rvm pkg install openssl
rvm install 2.3.0 --with-openssl-dir=$HOME/.rvm/usr

or

# alternative using rbenv recipe
brew install rbenv/tap/[email protected]
rvm install 2.3.0 --with-openssl-dir=$(brew --prefix [email protected])

[BanzaiMan]

@hurricup Do you have a URL to the working build?

[hurricup]

No. This is how I set up locally. But travis for some reason can't do the same. And this is really strange.

[BanzaiMan]

With

language: generic
os: osx
osx_image: xcode10.3
before_install:
  - env HOMEBREW_NO_AUTO_UPDATE=1 brew install rbenv/tap/[email protected]
  - rvm reinstall 2.3.0 --with-openssl-dir=$(brew --prefix [email protected])
install:
  - true
script:
  - "ruby -v -ropenssl -e \"puts OpenSSL::VERSION\""

You can compile OpenSSL 1.0 and Ruby 2.3.0

This takes about 30 minutes.

[hurricup]

I presume travis could pre-build them and use like binary distribution. I know it's kinda tricky on macos, but still possible.

[BanzaiMan]

In theory, yes, but I have not found a way to play nicely with Homebrew.

[native-api]

I have not found a way to play nicely with Homebrew.

brew install rbenv/tap/[email protected] <- doesn't this count as "nice"?

[BanzaiMan]

As in, bundling up what Homebrew writes on the build machine in such a way that can be reused elsewhere. Some of it might be simulated by caching, but it seems to fail in a very hard-to-understand ways.

Ruby 2.4 support is already dropped. I question the benefit of continuing to support 2.3, to be honest.

[hurricup]

The question is not about lifetime from devs, but usage statistics. Like https://stats.rubygems.org/

[native-api]

As in, bundling up what Homebrew writes on the build machine in such a way that can be reused elsewhere.

Since this is RVM's problem, you either supplement its logic in travis-build (brew install before rvm install), tap into its logic (I don't know how you tap into it to use https://rubies.travis-ci.org/ since the relevant logic is not on Github so can't say) -- maybe something similar, or make a PR against it to fix the problem for everyone.

Alternatively, you can use rbenv for affected versions who have already fixed that problem for themselves (I don't know how compatible their Ruby installation is though).