Repository navigation
NodeJS 18 revert to building on CentOS 7, RHEL 7, Ubuntu Bionic 18.04, other other LTS distros #43246
Description
What is the problem this feature will solve?
Moving to RHEL 8 has raised the glibc version being linked against
(2.28). The official Node.js Linux release binaries will only run on
Linux distributions with a matching or higher version of glibc.
#42659
nodejs/build#2815
nodejs/build#2741
What is the feature you are proposing to solve the problem?
Building on one of these older distros. All of them have support well past the EOL of NodeJS 18 when paired with paid or free (through sponsorship) extended support.
The breaking change that has been implemented will cause many projects dependent on NodeJS to drop centos 7, rhel 7, and (more importantly) Ubuntu bionic and Ubuntu 18 (bionic in snaps).
One of the most important projects dependent on nodeJS 18 using bionic or an older distro is Electron https://www.electronjs.org/docs/latest/faq#when-will-electron-upgrade-to-latest-nodejs This of course will trickle down to 1000s of dependent projects. Many developers use the official nodejs binaries in their projects
if we compare the linux support to window support, we can clearly see that linux is the least backwards supported platform requiring glibc 2.28 which released in August 1st 2018 (and wasn't included in distros until even later), while Windows has support for versions going back to 2015 for tier 1 support.
you say:
we do not want to have to make a disruptive change
towards the end of Node.js 18's life cycle.
when this would actually be the best thing to do. support the LTS versions for as long as the LTS version support exists. You can of course support it further than the LTS distros are supported (by purchasing or using the sponsored extended support).
What alternatives have you considered?
Notify all open source projects on github to NOT use NodeJS 18 through a custom github bot and to remain on prior NodeJS releases (eg, 16.x) until absolutely necessary.
Activity
cobalt2727 commentedon May 30, 2022
This would also solve nodesource/distributions#1392 - right now, the NodeSource build system is shipping completely broken packages to users, and has been for over a month now, with no official response given as to how this will be addressed.
rapito commentedon May 30, 2022
Albeit upgrading some linux distros to newer versions because of security updates and such would practically "get rid of the issue", some CI tools (in my case running on Ubuntu 18.04) depend on some scripting pipelines made in nodejs. It's dependency of glibc is breaking builds and automated pipelines on many environments for me.
Notably this is not addressing any real security patches or updates that would justify forcing glibc on the OS.
targos commentedon May 30, 2022
@nodejs/build
bnoordhuis commentedon May 30, 2022
One good reason for dropping support for CentOS/RHEL 7 is glibc. CentOS 7 ships with glibc 2.17 but node's dependencies are moving to newer versions.
(In fact that already happened but we're working around it for now. Not a viable long-term strategy though.)
Ubuntu 18.04 ships with glibc 2.27. That's probably new enough to last until v18's EOL.
rvagg commentedon May 30, 2022
Some background can be found in nodejs/build#2815, and specifically on this @ nodejs/build#2741
But the headline is this:
Unfortunately this happens on a regular cadence, we have to deal with this every few years, as do other major projects. It sucks for users, I hate it as someone who maintains a few systems on ancient versions of Linux. But you have the option of building Node.js yourself - if you can - V8 is going to get in your way over time here as it moves faster in its minimum requirements than we probably would be and we've regularly been forced to up our minimums just to support V8 (sometimes we manually patch to maintain backward compatibility!).
[-]NodeJS 18 revert to building on CentoOS 7, RHEL 7, Ubuntu Bionic 18.04, other other LTS distros[/-][+]NodeJS 18 revert to building on CentOS 7, RHEL 7, Ubuntu Bionic 18.04, other other LTS distros[/+]cobalt2727 commentedon May 30, 2022
nodejs/node-v8#220
V8 requires 2.27, no? What other dependencies, if any, are getting in the way?
nodejs/build#2815 (comment)
And if you guys have ESM licenses, all the more reason to continue to target 18.04.
itmustbe commentedon May 30, 2022
I also wish that there had at least been a warning that Node 18.x.x was incompatible with CentOS 7. And I'd certainly cast a vote for maintaining compatibility with CentOS 7 and similar distros if possible!
Although I'm only a tinkerer with Linux, I do have a significant non-profit website running on my little server. I try to keep everything up-to-date on my server, and during a routine update of Node.js, I encountered the dreaded 503 error on the website I'd just updated (thankfully a staging site).
I've rolled back to 17.9.0 for the foreseeable future, but it always makes me nervous having things like Node.js getting more and more out-of-date.
CentOS 8 is something I'm planning on, but it requires planning and time to migrate, and I will not have the time to dedicate to that project for awhile yet. I also lack the knowledge on building Node.js myself.
mhdawson commentedon May 31, 2022
There was a warning in the release blog post - https://nodejs.org/en/blog/announcements/v18-release-announce/#toolchain-and-compiler-upgrades.
@itmustbe for the future what do you think would have been the best channels to use in advance of the release itself to get the news out?
cobalt2727 commentedon May 31, 2022
Once again, V8 is a non-issue for 18.04. They're explicitly still supporting 18.04 by making the target glibc 2.27, which 18.04 runs with.
mhdawson commentedon May 31, 2022
@cobalt2727 I think the comment above in #43246 (comment) sums it up well. There are a number of different factors that went into the decision available (build team resources, support time lines, deps, future risk, etc.) and with a supported version of Node.js 16.x being available for another 2 years it's the balance we chose between the needs of the project and ends users.
cobalt2727 commentedon May 31, 2022
I would like to invite you guys to reconsider and reread the original post - breaking support for an OS that's perfectly capable of running NodeJS has a high chance of causing problems in thousands of projects for anyone on 18.04 for whatever reason well before before EoL hits. The balance you're describing only works if projects just... don't use 18 for a while, and lose out on feature updates until then.
So far, other than a misunderstanding of V8 requirements, I don't see the issue with continuing to provide official builds for 18.04. May as well put those ESM licenses to good use, yeah?
richardlau commentedon May 31, 2022
We don't have ESM licenses. nodejs/build#2815 (comment) mentions that they were not followed up on.
itmustbe commentedon May 31, 2022
I appreciate there are many aspects to Node.js development that I don't closely follow, and probably should have.
What happened in my case is that I run a virtual private server on CentOS 7 with Virtualmin/Webmin, and an update was flagged "Version 18.2.0 is available". Nothing stopped me from pushing the button to update Node.js on an unsupported system, and I rather wish something had done, as the website in question immediately went down with a 503 error for now-obvious reasons (not supporting the latest GLIBC etc. owing to the outdated version of libstdc++).
I contacted the folks who manage Virtualmin/Webmin, and they will be locking old distros to the correct version of Node.js so that this doesn't keep happening to other people in similar situations.
52 remaining items
theofficialgman commentedon Jul 3, 2023
@richardlau @rvagg please give this a shot. takes 2 mintues of your time. should lower the requirements to 2.17 (assumes cross compilers in standard ubuntu paths and deb commands, you should be able to pretty easily adapt for RHEL with rpm via similar methods)
libgdx/Jamepad@5eb5f30
theofficialgman commentedon Jul 3, 2023
I'd implement that for you but unfortunately your buildscripts and server configs are still closed source nodesource/distributions#1491
theofficialgman commentedon Jul 6, 2023
Looks like official NodeJS builds do NOT work on Debian buster either
https://nodejs.org/dist/v20.3.1/node-v20.3.1-linux-armv7l.tar.xz
node: /lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by node)theofficialgman commentedon Jul 6, 2023
@richardlau docs are incorrect, see above comment. NodeJS binary builds not compatible with GLIBC 2.28 on armv7l
https://github.com/nodejs/node/blob/main/BUILDING.md#official-binary-platforms-and-toolchains
leqii-com commentedon Dec 7, 2023
我想问下大佬们，node18及以上版本在centos7和8上都不被支持了吗？因为今天centos7.5系统上运行node18.0.0，安装后用不了，报了如下错误：
node: /lib64/libm.so.6: version
GLIBC_2.27' not found (required by node) node: /lib64/libc.so.6: versionGLIBC_2.25' not found (required by node)node: /lib64/libc.so.6: version
GLIBC_2.28' not found (required by node) /usr/local/bin/node: /lib64/libm.so.6: versionGLIBC_2.27' not found (required by /usr/local/bin/node)/usr/local/bin/node: /lib64/libc.so.6: version
GLIBC_2.25' not found (required by /usr/local/bin/node) /usr/local/bin/node: /lib64/libc.so.6: versionGLIBC_2.28' not found (required by /usr/local/bin/node)kajtzu commentedon Dec 7, 2023
You can find the URL to unofficial builds here nodejs/unofficial-builds#69 (comment), they will work on CentOS7. You will want an archive ending glibc217.tar.gz or .xz.
HTH.
leqii-com commentedon Dec 7, 2023
@kajtzu 非常感谢你，真的可以，根据你给的帖子，下载了这个https://github.com/momiji/nodejs-unofficial-builds/releases/download/v1.0.0/node-v18.14.2-linux-x64-glibc-217.tar.gz
哈哈！Thanks very much
BlackSunshine-manage commentedon Feb 13, 2024
@kajtzu 非常感谢你，真的可以，根据你给的帖子，下载了这个
Thank you very much, I pray for your health
OneCodeMonkey commentedon Apr 29, 2024
真是坑啊，你们不知道 Centos7 的市场保有量多大吗？说不支持 就不支持了？？
kajtzu commentedon Apr 29, 2024
It is EOL 30.6.2024 just like RHEL7 ;)
sbwml commentedon Apr 29, 2024
Announcing up to 4 years of Extended Life Cycle Support (ELS) for Red Hat Enterprise Linux 7
https://www.redhat.com/en/blog/announcing-4-years-extended-life-cycle-support-els-red-hat-enterprise-linux-7
leqii-com commentedon Apr 29, 2024
@OneCodeMonkey 没办法，谁叫咱要用他们的东西，所以要摆脱依赖
javaaiorg commentedon Jun 7, 2024
Use Node.js no GCC depends version can solved this problem:
https://www.javaai.org/a/c892d1e98fd94a64018ff4a88ec9000c
leqii-com commentedon Jun 13, 2024
@javaaiorg Get。太牛了，没有GCC也能用nodered，长见识了，十分感谢。
mhdawson commentedon Jul 12, 2024
@sbwml it's necessary to look carefully about what is included/not included in the Extended Life Cycle Support (ELS) for Red Hat Enterprise Linux 7. I'm not the authority but I don't believe it includes all runtimes.