fix: add python3.10 for x64 pointer compression and enable node >=22

[mistic]

This PR enables x64 pointer compression again when building Node.js >=v22 at the same time it fixes the previous build problem with python language syntax by installing python 3.10 from source.

[mistic]

\cc @rvagg

[rvagg]

ok, that's certainly an option
how long does it take to build? have you run this locally with >=22?

[mistic]

Yes I tried this locally and it didn't take that much on my M1 laptop.

In total it took 232 seconds, the breakdown was:

• 103 seconds running the previous yum install
• 129 seconds running the new yum groupinstall + yum install + make

[rvagg]

Thought I'd try it locally with v23 and it doesn't work:

g++: error: unrecognized command line option '-std=gnu++20'; did you mean '-std=gnu++2a'?
make[2]: *** [deps/simdutf/simdutf.target.mk:94: /home/node/node-v23.0.0/out/Release/obj.target/simdutf/deps/simdutf/simdutf.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:137: node] Error 2
make: *** [Makefile:1281: node-v23.0.0-linux-x64-pointer-compression.tar] Error 2

So you're going to have to update the rules to be -lt "23"

[rvagg]

compiled v22.0.0 fine (probably should have run a later version but I assume it's been stable)

[mistic]

@rvagg we can do that to fix it for now on node v22 but what about v23? I think we only have the option to change the base OS into a recent one or build gcc11 from source as well. Should we do that change right now on this PR? If thats the case we are probably better by going the route of updating the base OS maybe Alma/Rocky or Ubuntu (as it is already used in other images as well)?

[rvagg]

probably a separate PR, just put that -lt "23" in here and we can merge this and then deal with an upgrade separately

[mistic]

alright, in that case just pushed the change you mentioned.

regarding replacing the base OS , should we go with Ubuntu which is already one used in other recipes or do you prefer us to go into Alma/Rocky ?

[rvagg]

One reason to continue to use centos if we can is that we get older libc compatibility, Ubuntu brings us further into the future and limits compatibility of the binaries. I've lost of track of which glibc matches which distro (I had a fight with a wikipedia editor who deleted the absolute best source of this information and I don't know of another source).
What I would do first is quickly research the devtoolsets and find the lowest one that supports the minimal compiler we need, then if that devtoolset is available for the centos we run we should install that and use it. Then we get newer compiler but older libc. That's the magic of the RHEL ecosystem we're trying to tap into here.

We could bug @richardlau for advice too, he's probably up to date.

[richardlau]

I've lost of track of which glibc matches which distro

I usually use https://distrowatch.com/ (e.g. https://distrowatch.com/table.php?distribution=ubuntu for Ubuntu) which is handy if you're looking at one distro, but a bit more work if you need to compare across distros.

Adoptium keep their own wiki tracking OS End-of-Life dates which includes glibc versions to help with their own planning: https://github.com/adoptium/infrastructure/wiki/End-of-support-date-for-OS-distributions

If you want to keep close to how the official binaries on nodejs.org are built -- we use RHEL 8 for those and for the unofficial builds here, since containers are used, Universal Base Image (UBI) 8 would be good enough to build Node.js. From RHEL/UBI 8 devtoolsets were replaced by gcc-toolsets. One downside of UBI is that unlike RHEL out-of-support packages get retired from the repository, see https://github.com/nodejs/build/blob/main/ansible/roles/docker/templates/rhel8.Dockerfile.j2 for example on workarounds we need to install gcc-toolset-10. For this repository, it should not matter if a newer gcc-toolset is used (e.g. gcc-toolset-12).