Old Rubies fail to build

[pointlessone]

Steps to reproduce the behavior

Try building some old Rubies:

• rbenv install 2.3.8
• rbenv install 2.2.10
• rbenv install 2.1.10

Expected vs. actual behavior

In short, I'd expect them to build but they don't.

New clang (16.o in my case) has a some different defaults or something and that is a bit incompatible with old Rubies.

It seems adding -std=c89 -Wno-implicit-function-declaration to CFLAGS makes the errors go away.

Similarly, old Rubies can't build with new OpenSSL. I poked around in the ruby-build source and it seems at least at some point it could build and install older OpenSSL but it doesn't seem to do that any more. At least as far as I can tell it unconditionally picks OpenSSL 1.1 from brew.

I tried pointing it to my own OpenSSL 1.0.2 (rbenv install 2.3.8 -- --with-openssl-dir=/old/openssl-1.0) but that didn't work, it still picks the one from brew. I'm not sure what the issue is there.

### Other potentially useful information

``` $ clang --version Apple clang version 16.0.0 (clang-1600.0.26.4) Target: x86_64-apple-darwin24.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin ``` ``` $ /usr/bin/env bash --version GNU bash, version 5.2.32(1)-release (x86_64-apple-darwin23.4.0) ``` ``` $ brew --version Homebrew 4.4.5 ``` ``` $ brew info openssl ==> openssl@3: stable 3.4.0 (bottled) Cryptography and SSL/TLS Toolkit https://openssl-library.org Installed /usr/local/Cellar/openssl@3/3.4.0 (7,236 files, 33.8MB) * Poured from bottle using the formulae.brew.sh API on 2024-11-10 at 00:46:43 From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/o/openssl@3.rb [...] ``` ``` System Version: macOS 15.2 (24C5079e) Kernel Version: Darwin 24.2.0 ```

Logs

Ruby 2.3.8

MAKE_OPTS="-j 1" rbenv install 2.3.8

MAKE_OPTS to make the log legible. Otherwise it's a mush of 16 output streams and it's very hard to read but the result is the same.

STDOUT

``` ==> Downloading ruby-2.3.8.tar.bz2... -> curl -q -fL -o ruby-2.3.8.tar.bz2 https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.8.tar.bz2 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 13.7M 100 13.7M 0 0 16.7M 0 --:--:-- --:--:-- --:--:-- 16.7M ==> Installing ruby-2.3.8... WARNING: ruby-2.3.8 is past its end of life and is now unsupported. It no longer receives bug fixes or critical security updates. ruby-build: using readline from homebrew ruby-build: using libyaml from homebrew ruby-build: using gmp from homebrew -> ./configure "--prefix=$HOME/.rbenv/versions/2.3.8" --with-readline-dir=/usr/local/opt/readline --with-libyaml-dir=/usr/local/opt/libyaml --with-gmp-dir=/usr/local/opt/gmp --with-openssl-dir=/usr/local/opt/openssl@1.1 -> make -j 1 BUILD FAILED (macOS 15.2 on x86_64 using ruby-build 20241105) You can inspect the build directory at /var/folders/7h/dnvr79_s6dq18fs30mvwxpch0000gn/T/ruby-build.20241114184514.84070.0vsgFY See the full build log at /var/folders/7h/dnvr79_s6dq18fs30mvwxpch0000gn/T/ruby-build.20241114184514.84070.log ```

ruby-build.20241114184514.84070.log

[mislav]

In short, I'd expect them to build but they don't.

These versions of Ruby typically won't compile on modern systems. The main problem is that compilers and related tooling keep evolving, but these Ruby versions are long-unsupported and haven't kept up with the times. Furthermore, as you've already discovered, they depend on OpenSSL 1.0 which is also unsupported.

However, you are on the right track to work around your problems. I can't suggest a fix for your issue directly, but our Discussion forums are full of people trying to compile these old versions, failing at first, but then discovering the magic incantation in the end. If you search past discussions, you might find some workarounds as well.

I tried pointing it to my own OpenSSL 1.0.2 (rbenv install 2.3.8 -- --with-openssl-dir=/old/openssl-1.0) but that didn't work, it still picks the one from brew. I'm not sure what the issue is there.

That's odd: it looks like this Ruby bug for which ruby-build was supposed to have a workaround since December 2023: https://github.com/rbenv/ruby-build/pull/2322

You could try the following:

PKG_CONFIG_PATH=/old/openssl-1.0/lib/pkgconfig:$PKG_CONFIG_PATH rbenv install 2.3.8 -- --with-openssl-dir=/old/openssl-1.0

[mislav]

(Forgot to close) Closing this because it's not a bug with ruby-build. This project is only meant to help streamline compiling from source, but it can't help you if the upstream project (the Ruby source itself, or OpenSSL 1.0) is unsupported. As of this writing, the oldest supported Ruby version is Ruby 3.1, and the oldest supported OpenSSL version is OpenSSL 3.0.

So if you ever find yourself needing to install older versions of those software, you may be successful but be prepared to jump through some hoops (like supplying extra arguments and environment variables).

[pointlessone]

I understand that old Rubies are past their EOL and that old OpenSSL is likewise unsupported upstream.

That said, presence of definitions creates some expectation that ruby-build would be able to build them. Demand might be low and fixes might be of lower priority, granted.

So in light of that, do you think it's prudent to remove definitions for unsupported Rubies? Or, alternatively, would you accept fixes that would allow building older Rubies?

[pointlessone]

That's odd: it looks like this Ruby bug for which ruby-build was supposed to have a workaround since December 2023: https://github.com/rbenv/ruby-build/pull/2322

My bad. I had it set in RUBY_CONFIGURE_OPTS, dirty env.

Without it ruby-build does atapt to install older OpenSSL, but it fails too because OpenSSL requires special configuration to build on newer systems, too.

[mislav]

It sounds like you solved your immediate problem. I'm glad!

So in light of that, do you think it's prudent to remove definitions for unsupported Rubies?

No, I don't think it's ever appropriate to remove old definitions from ruby-build. This is because people might still need to install unsupported Ruby versions to run their old apps, even if they're doing so at their own risk. We do print a warning whenever you're trying to install an unsupported version: https://github.com/rbenv/ruby-build/pull/2471/files

Or, alternatively, would you accept fixes that would allow building older Rubies?

Yes, we welcome fixes if they help solve common pitfalls when building Ruby, even for unsupported Ruby versions. For example, the PKG_CONFIG_PATH workaround that we added last December is meant for Ruby < 2.7.7, which was already unsupported at that time, but it was easy to add and it had no known drawbacks.

However, we would only accept fixes that are relatively simple and risk-free. If a fix is too convoluted, such as applying patches to Ruby to help it compile, or applying compiler flag that might work only on some systems/compilers but not on others, then we'd rather do nothing and accept the fact that the user will get an error.

[hsbt]

I agreed previous @mislav 's comment.

@pointlessone I have a simple build script with patchsets for building old Ruby: https://github.com/hsbt/old-ruby-build . If you need to build old Ruby for modern macOS, It may helps you.