Nodejs bindings seem to depend on glibc 2.28, which breaks support with some distros

[Half-Shot]

Our new matrix-hookshot release now depends on this package, however users have reported that they cannot start the application on older Linux distros due to the bindings requiring a really new glibc.

Rust's own blog suggests a much older version dependency https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html

[Hywan]

Hello,

Thanks for reporting the issue.
Are you using the prebuilt of matrix-sdk-crypto-nodejs? If yes, then it depends of the glibc version that is used by Github Actions. We could change that, if it impacts a large portion of your users. Otherwise I would suggest to build the extension by hand, as described in the Development Section. Actually, I would suggest to first try this approach to see if it fixes the issue. What do you think?

[jplatte]

Yeah, we probably shouldn't be using ubuntu-latest to build these. Since this is a library that's dynamically loaded, the standard workaround of statically linking musl unfortunately doesn't work, but we can use an older distro.

[Half-Shot]

I'd +1 to picking an older distro for packaging :). We can certainly test if building our own binaries helps, but you might want to rework the binding layer so that it attempts to autobuild the binary for unsupported systems, rather than downloading something too new?

[Hywan]

Which glibc version, or Linux distro, do you need to support? Github Actions supports down to Ubuntu 20.04, which seems too recent for your needs (I don't have much more details rather than “on older Linux distros”, can you elaborate this part please?).

Edit: We can still install another glibc version on any Linux distros, but things get complicated pretty quickly, hence my questions.

[jplatte]

The usual solution is building inside a container, the GH actions runners should already come with Docker running.

[HarHarLinks]

Which glibc version, or Linux distro, do you need to support?

The issue was originally reported with Ubuntu 18.04 which still has LTS until early 2023 and includes glibc 2.27.
CentOS 7 (LTS until 2024) is on glibc 2.17.
Rocky Linux and Debian oldstable (buster) have 2.28.

[jplatte]

Hm, so 2.28 from Debian oldstable (buster) would be easy to build with, there's official Rust Docker images based on that. Supporting 2.27 (Ubuntu) or 2.17 (RHEL / CentOS) would be harder..

[gnunicorn]

We can also still run the github action on 18.04 until December first;) for building the libs ... https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/

[jplatte]

I.. guess that's the easiest immediate fix? But not very helpful for the future beyond Dec 1st 😄

[gnunicorn]

Sure ... but I think building on oldest Ubuntu LTS available on Github is a reasonable (and easy to do and maintain) minimum requirement for us to support - it is already a 5 year old system. I am not sure I want to give any guarantees that we offer support for things older than that. And yeah, there is a 4month timeframe where we'd already not be supporting the oldest LTS still active but I think that is okay (and should really be the time you start upgrading latest).

(smirky side note: I warned explicitly about these kinda hairy stuff we suddenly have to deal with if we start providing binaries...)

[Half-Shot]

GitHub swallowed my comment but: At least on bridges, we don't explicitly state what distro versions we support and could very easily say from our side that 18.04 is too cumbersome to support.

[Hywan]

I'm fine migrating back to Ubuntu 18.04 if it helps you right now. However, either the user of the lib should build it manually, or we should clarify which versions of what we support for the prebuilt binaries, but for sure we cannot provide prebuilts for super exotic or old environments.

So, what would you prefer us to do :-)? Migrating back to Ubuntu 18.04 (for a couple of months)? Or stating prebuilts are limited to certain constraints, and the user has to go through the manual build process if the environment doesn't fulfill those constraints?