Allow installation of Ruby 2.7, 3.0, 3.1 on Fedora >= 42

[pboling]

Fixes #2542

Sadly this only allows installation of Ruby 3.1, as it fails in a different way on Ruby 3.0. UPDATE: This works as-is for Ruby 3.0 once a C++ compiler is installed (aside: why does Ruby 3.0 need C++?).

sudo rpm-ostree install gcc-c++
systemctl reboot

This is an alternative resolution for #2529, and partially obviates the need for the entry in the wiki (at least it bumps back the need for an external solution to Ruby < 2.7).

Also worth noting that the workaround in the wiki is not possible on Fedora Atomic Desktop systems, e.g. Universal Blue-based Aurora, Bazzite, BlueFin, or uCore, because they disable the dnf tool for installing software (due to being "Atomic").

> ruby-build 3.1.7 ~/.rubies/ruby-3.1.7

==> Downloading ruby-3.1.7.tar.gz...by-3.1.7
-> curl -q -fL -o ruby-3.1.7.tar.gz https://cache.ruby-lang.org/pub/ruby/3.1/ruby-3.1.7.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 19.8M  100 19.8M    0     0  10.1M      0  0:00:01  0:00:01 --:--:-- 10.1M
==> Installing ruby-3.1.7...

WARNING: ruby-3.1.7 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
-> ./configure "--prefix=$HOME/.rubies/ruby-3.1.7" --enable-shared --with-readline-dir=/home/linuxbrew/.linuxbrew/opt/readline --with-ext=openssl,psych,+
-> make -j 22
-> make install
==> Installed ruby-3.1.7 to /home/pboling/.rubies/ruby-3.1.7

[mislav]

This is great; thank you! Some minor suggestions, only one important

[mislav]

After this is merged, does it fully alleviate the need to downgrade to gcc14 as currently outlined in workarounds in the wiki?

[pboling]

Yes it does, for Ruby 3.1, and assuming you have a c++ compiler installed, which was probably already a pre-requisite, it also works for Ruby 3.0 and Ruby 2.7.

[pboling]

@mislav My only real qualm here is that the fix is actually unrelated to fedora. Its a fix for GCC v15. The issue is we don't have a parser for GCC version as far as I can tell.

In an ideal world we would adjust the CFLAGS based on GCC version so the flavor of linux isn't relevant. Perhaps this is good enough for now; it can be iterated on, and solves a decent chunk of current and future installed base (RedHat will be rolling out GCC v15 soon, if it hasn't already, since Fedora is the canary).

[pboling]

@mislav My only real qualm here is that the right fix would be unrelated to fedora. Its a fix for GCC v15. The issue is we don't have a parser for GCC version as far as I can tell.

In an ideal world we would adjust the CFLAGS based on GCC version so the flavor of linux isn't relevant. Perhaps this is good enough for now; it can be iterated on, and solves a decent chunk of current and future installed base.

[mislav]

My only real qualm here is that the right fix would be unrelated to fedora. Its a fix for GCC v15. The issue is we don't have a parser for GCC version as far as I can tell.

That's a good point. I would vote that we merge this PR as-is right now as it fixes a more immediate problem, then as more operating systems upgrade to GCC v15 and this continues to be a problem, update to gcc version detection.

How hard would scanning the output of gcc --version be? Could you share your own output? Does the output vary a lot across systems?

[pboling]

@mislav I have two types of gcc version output on Fedora 42:

gcc -v

➜  gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,cobol,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-libstdcxx-backtrace --with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-15.1.1-build/gcc-15.1.1-20250521/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.1.1 20250521 (Red Hat 15.1.1-2) (GCC) 

where the key line is: gcc version 15.1.1 20250521 (Red Hat 15.1.1-2) (GCC)

and

gcc --version

➜  gcc --version
gcc (GCC) 15.1.1 20250521 (Red Hat 15.1.1-2)
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

where the key line is: gcc (GCC) 15.1.1 20250521 (Red Hat 15.1.1-2)

[pboling]

This site has a table of the default modes for each version up to v13:

https://sc.ddbj.nig.ac.jp/en/guides/software/DevelopmentEnvironment/gcc/

Fortunately, based on that table, we don't need to do much switching at all!

[tomwrobel]

Just to bump the issue, there's a bug here that will raise an arithmetic error in bash for any OS that returns a decimal point for $VERSION_ID (such as RHEL): #2546