Repository navigation
NodeJS 18 revert to building on CentOS 7, RHEL 7, Ubuntu Bionic 18.04, other other LTS distros #43246
Description
Activity
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.
Reacted by Robert Peralta, julestalbotier, qurious-pixel and romaleAlbeit 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.
@nodejs/build
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.
Reacted by Aditya PandeySome 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!).
- changed the title
[-]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[/+]on 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.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.
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?
Reacted by Per TillischOnce 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.
@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.
Reacted by Graham Ballantyne, Jaden, KSR-Yasuda and Jorge Luis LazoI 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?
Reacted by Benoit Tigeot and Jorge Luis LazoWe don't have ESM licenses. nodejs/build#2815 (comment) mentions that they were not followed up on.
Reacted by CobaltI 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
@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@5eb5f30I'd implement that for you but unfortunately your buildscripts and server configs are still closed source nodesource/distributions#1491
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)@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我想问下大佬们，node18及以上版本在centos7和8上都不被支持了吗？因为今天centos7.5系统上运行node18.0.0，安装后用不了，报了如下错误：
node: /lib64/libm.so.6: versionGLIBC_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: versionGLIBC_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: versionGLIBC_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)我想问下大佬们，node18及以上版本在centos7和8上都不被支持了吗？因为今天centos7.5系统上运行node18.0.0，安装后用不了，报了如下错误：
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.
Reacted by leqii-com and Jody Hoon-Starr@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 muchReacted by Kaj J. Niemi, leqii-com and HE HUANG@kajtzu 非常感谢你，真的可以，根据你给的帖子，下载了这个
Thank you very much, I pray for your health
真是坑啊，你们不知道 Centos7 的市场保有量多大吗？说不支持 就不支持了？？
What a pit, don't you know how much Centos7 has in the market?
It is EOL 30.6.2024 just like RHEL7 ;)
Announcing up to 4 years of Extended Life Cycle Support (ELS) for Red Hat Enterprise Linux 7
Reacted by Kaj J. Niemi@OneCodeMonkey 没办法，谁叫咱要用他们的东西，所以要摆脱依赖
Use Node.js no GCC depends version can solved this problem:
https://www.javaai.org/a/c892d1e98fd94a64018ff4a88ec9000cReacted by kelvinji2009@javaaiorg Get。太牛了，没有GCC也能用nodered，长见识了，十分感谢。
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:
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.