search

mudge / re2

Ruby bindings to RE2, a "fast, safe, thread-friendly alternative to backtracking regular expression engines like those used in PCRE, Perl, and Python".
http://mudge.name/re2/
BSD 3-Clause "New" or "Revised" License
129 stars 13 forks source link

Restore Ruby 2.5 support #100

Closed mudge closed 1 year ago

mudge commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 https://github.com/rake-compiler/rake-compiler-dock/pull/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

stanhu commented 1 year ago

I think https://github.com/mudge/re2/pull/100/commits/e9c6ca477a45b651a1831b9fb4bc416ef089b4b6 worked: https://github.com/mudge/re2/actions/runs/6150549324/job/16688950710?pr=100

stanhu commented 1 year ago

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

mudge commented 1 year ago

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.)