fix: x64-glibc-217 build failed for v22.7.0

[robinWongM]

1. Upgrade GCC version to 12 and Python version to 3.8
2. Backport the patch from TCP_FASTOPEN_CONNECT build failure on CentOS 7 (or older kernels) c-ares/c-ares#850

[rvagg]

@richardlau would you mind checking this? you probably have more familiarity with devtoolsets these days -- if this runs on centos7, we're still going to retain glibc 2.17 support, right?

[robinWongM]

@richardlau would you mind checking this? you probably have more familiarity with devtoolsets these days -- if this runs on centos7, we're still going to retain glibc 2.17 support, right?

Yes, I've successfully tested the updated build process locally, and the resulting binary is compatible with glibc 2.17.

[robinWongM]

@rvagg can you trigger a rebuild for this? thanks

./bin/queue-push.sh -v v22.7.0 -r x64-glibc-217

[rvagg]

https://unofficial-builds.nodejs.org/logs/202408280055-v22.7.0/x64-glibc-217.log didn't work, maybe the recipe didn't propagate to a new build of the containers, needs investigation

[rvagg]

#153

[robinWongM]

https://unofficial-builds.nodejs.org/logs/202408280055-v22.7.0/x64-glibc-217.log didn't work, maybe the recipe didn't propagate to a new build of the containers, needs investigation

@rvagg maybe we need to rebuild images

cd bin
./prepare-images.sh

[rvagg]

Ran out of space on the root device, had other dramas, so I ended up clearing out the docker entirely and rebuilding them all again. I also reduced the ccache max size from 5G to 2G, each time we add a new recipe it ends up reserving that much on the root disk. Currently rebuilding and I can see glibc-217 working away right now so hopefully it'll drop in. We'll see what else succeeds and what passes. I think we have additional problems with other recipes to deal with.

[rvagg]

k, well we got a glibc-217 but aside from musl, everything else seems borked, probably a python thing