feat: add x64-old-glibc recipe

jwalton commented 1 year ago

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

Would you consider adding more architectures to this PR?

jwalton commented 1 year ago

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

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

cobalt2727 commented 1 year ago

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

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

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

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.