feat: add x64-old-glibc recipe

[jwalton]

This adds a recipe for buiding node 18 using older versions of glibc.

As of node 18, the minimum requirement for glibc2 has been updated to >=2.28 (as opposed to 2.17 in node 16). The reason for this change is that node 16 and below were built on RHEL7, but node 18 moved to building on RHEL8 because RHEL7 will be out-of-support during the lifetime of node 18. Since RHEL8 moves to glibc 2.28, node 18 has followed suit. However, node still compiles against glibc 2.17, and there are many platforms where node is used where this glibc is unavailable. The latest version of QNAP's QTS 5 only uses glibc 2.21. Synology is a little better at glibc 2.26, but still doesn't have 2.28. There are no doubt other cases where a node 18 with an older glibc would be very convenient.

This problem is compounded by the fact that the end-of-life for node 16 is coming up very soon as it's LTS period was shortened due to OpenSSL, meaning that node 16 isn't a viable option for many cases.

@sxa suggested that this might be a good "unofficial-builds" build, hence this PR.

[cobalt2727]

Would you consider adding more architectures to this PR?

[jwalton]

I can look into doing that. Are there specific architectures you're interested in? I'm more interested in the QNAP side, as we run node on several thousand Intel based QNAPs, so that's where my focus is. But if it's easy to do, I'm happy to add other architectures.

[cobalt2727]

aarch64 and armhf would be the two big ones imo - maybe i386 if anyone wants it, but I'm indifferent on that personally

[cobalt2727]

One thing to note is that there's tests being done on glibc 2.26+ support, but that wouldn't cover all distros affected by the glibc change.

[rvagg]

I'm fine with this and get the annoyance but have a few thoughts after looking through this:

• You should refer to glibc version in the docs rather than just using distro/platform names, the versions tend to be pretty helpful, especially when using the Version history table here: https://en.wikipedia.org/wiki/Glibc#Version_history to map to distros and versions (I have that bookmarked and have had many occasions to use it, you could even link to that).
• I think the glibc version should be in the name rather than "old", you can remove the . to make it work.
• Using third-party sources of devtoolset has always been a pain, they grow stale and get removed, I wouldn't be surprised to see the one you're using here disappear at some point and this whole thing fail. I'm not sure what to do about that other than pointing out that this is a brittle point.
• There's usually background to the glibc bumps in Node.js and I haven't followed this recent one to understand whether it's simply an EL lifecycle bump or something to do with V8. Historically we've had to bump because V8 has moved on and it's become impossible to maintain backward compatibility. Perhaps the devtoolset will bridge the gap for long enough, but I suspect there's a brittle point here too, with some future version of Node.js just not compiling on this.

[jwalton]

• Re: name: I was unhappy with the name, too. Changed to x64-glibc-217.
• Re: third-party sources of devtoolset: I totally copy-pasted this from x64-pointer-compression. ;)
• Re: Bumps in glibc: Yeah... this is going to be a brittle point for sure. Eventually I'll have to look at statically linking glibc and libnss, or I'll have to switch to running everything I do in Docker, or... something. :P But this works for now.

[cobalt2727]

I can confirm it's got nothing to do with V8, at least for the time being. Last I heard, it was just out of concern for CentOS 7 hitting its EoL (2024) during 18's LTS period (until 2025) or something.

[momiji]

Hardly waiting for a release to be available.
Until then, I forked and make it work and build at work , behind a corporate proxy. Advantage is it build in less than 10 minutes.
Looks like it works on our rhel 7 servers, I'll do more tests soon...

[kknicker]

I apologize that I don't know the etiquette here, but we are currently stuck on Node.js 16.x on our RHEL 7 servers because of the glibc 2.17 version there. I found this x64-old-glibc recipe was contributed in February and have been checking periodically since then. Is there any way to know if or when this pull request might be merged so the unofficial build will be available? I would appreciate any information.

[momiji]

Temporarily, builds are available here: https://github.com/momiji/nodejs-unofficial-builds/releases/

[kknicker]

Excellent, thank you.

[kknicker]

@momiji Can you please create a build for 18.16.0.

[momiji]

@momiji Can you please create a build for 18.16.0.

Sure, can you wait until next week? I'm currently on vacation ;-)

[kknicker]

@momiji Can you please create a build for 18.16.0.

Sure, can you wait until next week? I'm currently on vacation ;-)

Yes, definitely. Thank you.

[momiji]

v18.16.0 is now available, however I didn't test it yet, sorry.
@kknicker can you confirm it works once you got it?

[rvagg]

Let's deploy and see I guess!

The caveat here for all users is that this could break at any time and there's no pressure on nodejs/node to fix things to accommodate the breakage. Rely on this at your own risk. Once it breaks, we'll have to consider removing it from the regular build schedule here.

This is similar to all unofficial-builds, it's in the name, these are builds for toolchain permutations that are not in the normal nodejs/node priority / guarantee list.

I'm not going to force a run of an existing release of this, you'll have to wait till the next release(s) to get a build. Last time I re-ran an old release the change in SHASUMs was a problem for the Docker folks! I'm not sure how we're going to address that other than try not to re-run old builds.

[kknicker]

@momiji I downloaded the v18.16.0 temporary unofficial build from https://github.com/momiji/nodejs-unofficial-builds/releases/. I did some basic testing with our application and it is working. Thank you.

[momiji]

@rvagg Maybe we can also try to help on this? Maybe there is way to improve the build of the Docker images?

[rvagg]

these are now being built with every new node.js release, e.g. see the latest @ https://unofficial-builds.nodejs.org/download/release/v20.1.0/

The problem wrt Docker is simply that they depend on the SHASUMS file to be stable over time, so when we re-run an old build, we get new binaries and a new SHASUMS and their stuff breaks. I'm not sure exactly why it's set up the way it is for them but the new rule is - don't re-build old versions unless absolutely necessary.

If you want binaries of this recipe for older node.js versions then you're welcome to look into that problem over @ nodejs/docker-node, I don't recall the issue here where it came up last but it was a recent rebuild so somewhere in the issues list.