Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore Ruby 2.5 support #100

Closed
wants to merge 2 commits into from
Closed

Restore Ruby 2.5 support #100

wants to merge 2 commits into from

Conversation

mudge
Copy link
Owner

@mudge mudge commented Sep 11, 2023

While trying to justify the restoration of Ruby 2.6 support by looking at the stats from RubyGems.org, it appears that the third most popular Ruby version is still 2.5. It's not clear why this is but if it is easy for us to add support, this means we cover the top five most used Ruby versions according to https://ui.honeycomb.io/ruby-together/datasets/rubygems.org/result/HBSqTboW1yi (with the bonus of supporting 2.6 due to it being the default system Ruby on macOS Monterey).

While trying to justify the restoration of Ruby 2.6 support by looking
at the stats from RubyGems.org, it appears that the third most popular
Ruby version is still 2.5. It's not clear why this is but if it is easy
for us to add support, this means we cover the top five most used Ruby
versions according to
https://ui.honeycomb.io/ruby-together/datasets/rubygems.org/result/HBSqTboW1yi
(with the bonus of supporting 2.6 due to it being the default system
Ruby on macOS Monterey).
@mudge
Copy link
Owner Author

mudge commented Sep 11, 2023

Looks like the two failures are the same here:

version `GLIBCXX_3.4.26' not found (required by /usr/local/bundle/gems/re2-2.0.0.beta2-aarch64-linux/lib/2.5/re2.so) - /usr/local/bundle/gems/re2-2.0.0.beta2-aarch64-linux/lib/2.5/re2.so

@stanhu any ideas what might be causing that?

@stanhu
Copy link
Collaborator

stanhu commented Sep 11, 2023

@mudge The issue is that test-precompiled-arm-linux uses the ruby:2.5 image, which is based off Debian buster. This version of Debian uses glibc v2.28:

% docker run -it ruby:2.5 bash
root@4b4015adb990:/# dpkg -l | grep libc | head
ii  libc-bin                           2.28-10                      arm64        GNU C Library: Binaries
ii  libc-dev-bin                       2.28-10                      arm64        GNU C Library: Development binaries
ii  libc6:arm64                        2.28-10                      arm64        GNU C Library: Shared libraries
ii  libc6-dev:arm64                    2.28-10                      arm64        GNU C Library: Development Libraries and Header Files
ii  libcairo-gobject2:arm64            1.16.0-4+deb10u1             arm64        Cairo 2D vector graphics library (GObject library)
ii  libcairo-script-interpreter2:arm64 1.16.0-4+deb10u1             arm64        Cairo 2D vector graphics library (script interpreter)
ii  libcairo2:arm64                    1.16.0-4+deb10u1             arm64        Cairo 2D vector graphics library
ii  libcairo2-dev:arm64                1.16.0-4+deb10u1             arm64        Development files for the Cairo 2D graphics library
ii  libcap-ng0:arm64                   0.7.9-2                      arm64        An alternate POSIX capabilities library
ii  libcap2:arm64                      1:2.25-2                     arm64        POSIX 1003.1e capabilities (library)

This is because the arm64 builds in rake-compiler-dock use Ubuntu 20.04 as the base image, and that's why in the README.md we mentioned that glibc v2.29 is required. I originally tried to fix this in rake-compiler/rake-compiler-dock#68, but that change required QEMU instead of cross-compilation. I've considered sending an upstream fix to downgrade from Ubuntu 20.04 to 18.04 as the arm64 base image, but given that 18.04 has already reached EOL that idea doesn't seem prudent.

If we really want Ruby 2.5 support, we could update the CI job to use a current version of Ubuntu and install Ruby 2.5 on it rather than use the ruby:2.5 image.

@mudge
Copy link
Owner Author

mudge commented Sep 11, 2023

Given Ruby 2.5 support would be for people (presumably) stuck on old platforms, if it doesn’t work on the official ruby:2.5 image, maybe it’s not worth it. I was hoping it’d be a quick win after the tests passed locally (and after struggling to get Ruby to compile on my Mac, that is).

@stanhu
Copy link
Collaborator

stanhu commented Sep 11, 2023

Given Ruby 2.5 support would be for people (presumably) stuck on old platforms, if it doesn’t work on the official ruby:2.5 image, maybe it’s not worth it. I was hoping it’d be a quick win after the tests passed locally (and after struggling to get Ruby to compile on my Mac, that is).

Note this is only an issue with arm64, since the x86 image uses an older version of glibc. We could just build 2.5 for x86 only, though if users did try to use the package with 2.5 arm64 they would encounter a load error. Or we could just test arm64 and Ruby 2.5 separately.

@mudge
Copy link
Owner Author

mudge commented Sep 11, 2023

Is there a way for us to use our own arm64 image with the older glibc to build the gem (to match x86) or is that a massive ordeal?

@stanhu
Copy link
Collaborator

stanhu commented Sep 11, 2023

@mudge It appears that ruby:2.5-alpine uses Alpine v3.13, which works if you add the glibc compatiblity layer (apk add gcompat).

Standardize on using the Alpine Ruby base images since they tend to
use a more recent version of glibc. Since Alpine images don't include
`bash` and `gcompat` by default, add a wrapper
(`scripts/test-gem-install-sh`) for Alpine.
@stanhu
Copy link
Collaborator

stanhu commented Sep 11, 2023

@stanhu
Copy link
Collaborator

stanhu commented Sep 11, 2023

For some reason these arm-linux builds appear to be stuck: https://github.com/mudge/re2/actions/runs/6150549324/job/16688949452?pr=100

@mudge
Copy link
Owner Author

mudge commented Sep 12, 2023

I'm going to close this as I'm reticent to add Ruby 2.5 support that requires system dependencies newer than are available in the official ruby:2.5 image: that seems a smell that, in practice, users stuck on Ruby 2.5 wouldn't be able to use the native gem either.

(I would still love to know why Ruby 2.5 is so popular, outstripping both 3.1 and 3.2.)

@mudge mudge closed this Sep 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants