NodeJS 18 revert to building on CentOS 7, RHEL 7, Ubuntu Bionic 18.04, other other LTS distros
theofficialgman opened this issue · 75 comments
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.
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.
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.
@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.
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/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?
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.
@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.
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?
We don't have ESM licenses. nodejs/build#2815 (comment) mentions that they were not followed up on.
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.
@itmustbe thanks for the update/response. It does seem that stopping the notice that an update is available when it is not would help.
We don't have ESM licenses. nodejs/build#2815 (comment) mentions that they were not followed up on.
My mistake, sorry about that. Nonetheless, I think it's still worth supporting just for one more year.
electron and chromium have devised a very smart and interesting method for continuing to support GLIBC 2.17+ on their own builds for related projects. instead of using outdated distros to build on, they use distros like bullseye and sid but implement a binary rewrite script to relink the compiled binaries against glibc 2.17 and older functions.
https://source.chromium.org/chromium/chromium/src/+/main:build/linux/sysroot_scripts/reversion_glibc.py
this should be investigated for inclusion in NodeJS builds
accompanying this script, they also make patches to the sysroot they use to build on so that it will build binaries that can be successfully linked on glibc 2.17+
a few important lines from it are here: https://chromium.googlesource.com/chromium/src/+/HEAD/build/linux/sysroot_scripts/sysroot-creator.sh#324
I'm aware of that technique (another approach is to alias the symbols in asm) but it's hacky and fragile.
I can see it working for a project like chromium where there's a team of full-time engineers working to keep the build in good shape. For an OSS project that wants to maintain a semblance of stability it's a much riskier proposition.
You can of course run that script locally and cross your fingers.
might I ask then, what is the point of switching to a fully maintained distro anyway? you are using it to compile code, you only need functional GCC/G++. Each of the distros already mentioned in the title of this post are perfectly suitable for running modern compiler toolchains on.
yes I have fully read all of the relevant PRs, Issues, discussions, etc and this has never been publicly discussed. It appears to me that you just wish to update for the purpose of "gaining support" when that support doesn't actually do you any good. these are build servers. GCC packages haven't changed in years (for the specific version you target)
You yourself brought up that glibc symbol hack so you must be aware that it involves more than just a "functional GCC/G++".
You yourself brought up that glibc symbol hack so you must be aware that it involves more than just a "functional GCC/G++".
the symbol hack was so that you could continue to build on newer distros with higher version of glibc and then patch the versions of the symbols to be lower than that of the glibc shipped in the distro. there isn't anything that is in V8 that won't compile already with glibc 2.27 (or older, chromium still targets that).
obviously it would be easier to simply use an older distro which already has that older glibc version, but I was just stating options
We don't have ESM licenses. nodejs/build#2815 (comment) mentions that they were not followed up on.
this would probably be the best avenue to pursue. you need to keep in mind that the change from glibc 2.17 (what previously was required) to glibc 2.28 (what is now) is a full 6 YEAR version bump. that is huge
we also already know the glibc 2.27 bump was accidental and reverted: v8/v8@4e81f25 . they do not, and have not, done anything that requires glibc 2.27, 2.28, or anything modern. chromium and v8 still intend and have been building with a minimum of 2.17 in mind. Any attempt to say differently is misguided.
I don't think you can construe the conversation in https://bugs.chromium.org/p/v8/issues/detail?id=12682 as the V8 team saying they plan on supporting glibc 2.17 indefinitely. Even if they did, that's just one of Node's dependencies.
from glibc 2.17 (what previously was required) to glibc 2.28 (what is now) is a full 6 YEAR version bump
Sure, but that's because 2.17 is just really old. It was released in 2012. It's 2022 now!
I don't think you can construe the conversation in https://bugs.chromium.org/p/v8/issues/detail?id=12682 as the V8 team saying they plan on supporting glibc 2.17 indefinitely.
The fact that it was deemed a critical enough bug to get fixed in 10 days is more than enough to show they intend to keep supporting legacy glibc versions. So when deciding whether or not to upgrade the build system for NodeJS, v8 is evidently not something to take into consideration, period.
Even if they did, that's just one of Node's dependencies.
Now that we've established v8 is a non-issue, what other dependencies are getting in the way?
Not going to engage. I don't get the feeling you're arguing in good faith. At the very least your tone is off-putting.
Then I'd like to apologize for that - but I'm honestly wondering what other roadblocks there are.
Kinda on board with cobalt here. Now that it has been established that V8 isn't the problem then what is? If you tell people what the issue is then you might get more constructive discussion regarding the possible way of moving forward. Otherwise this goes nowhere.
Upstream fixed that memfd_create issue relatively quickly because it was breaking their fuzz bots. You can't extrapolate that into a commitment they're going to keep supporting glibc 2.17 until April 2025, v18's EOL date.
V8 and node's other dependencies (openssl, nghttp2, etc.) don't really make promises about minimum supported versions. Libuv does but, as a libuv maintainer, I can kind of promise we won't be supporting glibc 2.17 (edit: or centos 7 in general) until 2025.
What about finding a middle ground and continuing to support something like 2.27? (I'd suggest 2.24, but Debian 9 support ends this month so that would be kind of pointless...)
I touched on that in #43246 (comment). I can't speak for everyone but AFAIC that's on the table.
I don't think you can construe the conversation in https://bugs.chromium.org/p/v8/issues/detail?id=12682 as the V8 team saying they plan on supporting glibc 2.17 indefinitely. Even if they did, that's just one of Node's dependencies.
@v8 Hello, NodeJS would like to know from members of the V8 organization if there is any published (or unpublished) linux support guarantees. Specifically, they would like to know if glibc 2.17 (or some older version) can be guaranteed to have support in V8 until the EOL of nodejs 18 (April 2025). If V8 plans on bumping the glibc version requirement before the April 2025 date, is there a specific newer version that is going to be targeted?
I don't think you can construe the conversation in https://bugs.chromium.org/p/v8/issues/detail?id=12682 as the V8 team saying they plan on supporting glibc 2.17 indefinitely. Even if they did, that's just one of Node's dependencies.
@v8 Hello, NodeJS would like to know from members of the V8 organization if there is any published (or unpublished) linux support guarantees. Specifically, they would like to know if glibc 2.17 (or some older version) can be guaranteed to have support in V8 until the EOL of nodejs 18 (April 2025). If V8 plans on bumping the glibc version requirement before the April 2025 date, is there a specific newer version that is going to be targeted?
@FrankYFTang hi, do you know who we should contact for this?
+1
Need node 18 on CentOS 7.
I don't think you can construe the conversation in https://bugs.chromium.org/p/v8/issues/detail?id=12682 as the V8 team saying they plan on supporting glibc 2.17 indefinitely. Even if they did, that's just one of Node's dependencies.
@v8 Hello, NodeJS would like to know from members of the V8 organization if there is any published (or unpublished) linux support guarantees. Specifically, they would like to know if glibc 2.17 (or some older version) can be guaranteed to have support in V8 until the EOL of nodejs 18 (April 2025). If V8 plans on bumping the glibc version requirement before the April 2025 date, is there a specific newer version that is going to be targeted?
@FrankYFTang hi, do you know who we should contact for this?
@syg Do you know who may know that answer?
We do not give any guarantees for supporting a minimum glibc version with a target date. I agree with @bnoordhuis here: what https://bugs.chromium.org/p/v8/issues/detail?id=12682 shows is that where not too onerous, we're happy to try to accommodate V8 working on older glibc versions. We have not given any kind of guarantees here.
I'm also not aware of any plans to bump the glibc requirement in the future. It'll happen on a case-by-case basis depending on the use case.
I'm kind of confused though, probably because I don't know enough about Node's release model. Wouldn't a Node release pin a particular V8 version? If that particular V8 version supported the minimum glibc version you wanted, isn't that sufficient?
Thanks for confirming, @syg. That settles that discussion: glibc 2.17 / centos 7 is off the table.
glibc 2.27 / ubuntu 18.04 is provisionally on the table but needs a volunteer to drive the work. 18.04's maintenance ends in April 2023 so I'd pick that as the cutoff point.
Wouldn't a Node release pin a particular V8 version?
We upgrade as long as it's possible to retain C++ API and ABI compat with only minor tweaks (ex: 8d0bbf9)
Since this issue has been dormant for 3 months and 18.04's EOL is only 6 months away, it seems likely this won't happen anymore. Closing, but volunteers are of course still welcome to step up.
For what it's worth, RHEL 7's maintenance support ends in June 2024. Also, it looks like that 18.04 EoL is getting pushed back by way of Canonical's new Ubuntu Pro free tier.
In addition, this affects even more distros than previously discussed. See nodesource/distributions#1433 and nodesource/distributions#1402 for an example - and by the way, the EoL for Amazon Linux 2 is... June 2024 as well.
@bnoordhuis Would statically linking glibc2.28 on the packages for the mentioned distros be an option? I dunno how your build servers are set up but I can't imagine that would be too hard to include...
And it's not like anyone would care about any resulting increase in binary size - better than it not being supported.
Statically linking glibc is a can of worms, you can't really do it: https://www.google.com/search?q=glibc%20static%20linking
I mean, you're welcome to try but I expect you'll run into no end of issues. Then there's also libstdc++ to consider.
Could an approach like https://github.com/lulle2007200/sublime_on_arm64_bionic/blob/master/install_sublime.sh do the trick?
Downloading a copy of glibc and fixing up the binary with patchelf? Eh, I don't know. I doubt any maintainers want to be on the hook for supporting that, plus it's not like distro packagers would ever accept it.
You could open a pull request and see what other maintainers say. Even if it doesn't get merged, it'd still be something people can apply individually.
I would point out the the latest version of QNAP's QTS OS is glibc 2.21, and the latest Synology OS is glibc 2.26, so neither of these are capable of running node 18.
This would be less of an issue if not for the fact that node 16's LTS window was moved up 7 months and is less than a year away. In a very short time I suspect there will be no way to run an LTS Node on these devices.
For what it's worth, RHEL 7's maintenance support ends in June 2024. Also, it looks like that 18.04 EoL is getting pushed back by way of Canonical's new Ubuntu Pro free tier.
This is part of why the update occurred. RHEL7 stops being supported in June 2024. Node.js 18 is supported until April 2025 so it did no make sense to choose to build it on an distribution which was going to go out of support before the end of the support date for that Node.js release. Switching the build platform and glibc mid way through an LTS cycle would have been sure to be more problematic for the project maintainers than taking the decision up front as it would be a breaking change in the middle of a release's lifetime.
In a very short time I suspect there will be no way to run an LTS Node on these devices.
While I don't know what everyone's use case is I would also point out that it is, of course, still possible - and quite easy - to compile the Node.js codebase yourself on RHEL7 (or equivalent) to have it run against an older glibc as an alternative option. Even the latest main branch still works in that environment and passes the test suite. I haven't tried anything prior to that version though, and it would depend if you required any sort of official support for it... Your OS vendor may also wish to consider whether they want to do that for you.
I would also point out that it is, of course, still possible - and quite easy - to compile the Node.js codebase yourself on RHEL7 (or equivalent) to have it run against an older glibc as an alternative option.
I can personally confirm this works, but I have a few concerns.
Is there an official statement somewhere from the NodeJS dev team stating that support for older distros where NodeJS is installed via this method won't be broken for the duration of the distro's lifespan?
I'm 99% sure the answer to the above is no, but the point I'm trying to make here is I don't think that's a sustainable alternative long-term, even if it is currently...
Not to mention it makes updating more difficult if the user has to rebuild every time, given how long it takes to do so on most consumer hardware. Taking that a step further, it could arguably be a security risk unless you're checking manually for commits offering security patches constantly, no?
Apparently I didn't click "Commetn" on the last response that I wrote a few days ago so I'll re-draft it ...
Is there an official statement somewhere from the NodeJS dev team stating that support for older distros where NodeJS is installed via this method won't be broken for the duration of the distro's lifespan?
As you expected, the answer to that is "No". We cannot guarantee that. Unofficially I'd personally be very surprised if it was to stop working during the life of Node 18, but I would not wish to give any assurances. If it did break, we may still accept a patch to resolve it though if someone wished to diagnose it.
it could arguably be a security risk unless you're checking manually for commits offering security patches constantly, no
Correct, but that's the same with anyone downloading binaries from the web site. If you're using a package manager that will auto-update releases you won't have a problem, if you're downloading and extracting tarballs (which is all that the nodejs website providers) you still have to pay attention to new releases and pull them down to get security updates. And of course security (openssl in particular) is precisely why we had to make the unpopular decision to pull forward the support date for Node.js 16. Any of the alternatives would likely have cause far more problems. If you were concerned about security updates in openssl specifically you would also have the option when building yourself of linking against a system openssl instead of having it statically linked in so that you can get the patches from your regular OS updates.
To avoid the need to rebuild such an unsupported version it might be possible to have some suitable builds as part of the unofficial builds project that we have, but similarly that would not be something that we would support or guarantee to keep working as those are not part of the regular CI, so it would need someone to show an interest in keeping it working.
Apparently I didn't click "Commetn" on the last response that I wrote a few days ago so I'll re-draft it ...
No worries, it happens.
And of course security (openssl in particular) is precisely why we had to make the unpopular decision to pull forward the support date for Node.js 16.
Taking Ubuntu 18.04 as an example, they're still backporting security fixes into their outdated package versions, though, right? So if I'm understanding that correctly, I don't see how security is an issue there as long as the OS hasn't hit EoL yet (see #43246 (comment) again)
Taking Ubuntu 18.04 as an example, they're still backporting security fixes into their outdated package versions, though,
Short answer: Since Node statically links OpenSSL by default the version in the OS is irrelevant.
Long answer: Ubuntu (and RHEL) are presumably choosing to maintain patches for the version of OpenSSL supplied with their distribution and they will be doing that themselves, independently of the equivalent stream at the OpenSSL project. For Ubuntu 18.04 that would be some version of OpenSSL 1.1.1 (I'm not sure which one, but I believe Ubuntu generally fixes the version in their distribution so it won't necessarily be based on the latest - which can cause some confusion. I believe RHEL/CentOS patch 1.1.1g. Node 16 currently uses OpenSSL 1.1.1q) and those patches will not be against the appropriate codebase in the upstream OpenSSL project which Node.js pulls from.
If you build node and dynamically link against the system openssl supplied with Ubuntu, then you'll pick up the OS-patched openssl, but that is NOT how the Node.js default build process works - the statically linked version of OpenSSL in the Node.js distributions on our web site would not utilise the patching done by the OS vendor.
Alright, so if the version of (for example) OpenSSL being used isn't even the one from the package manager but rather a statically linked version, then... why would OpenSSL be relevant at all in the conversation about how long to extend support for?
Because if a vulnerability is identified in the (unsupported) version of OpenSSL included in Node.js, no-one will be patching it upstream so it will be vulnerable. This is all covered in the Node.js 16 EOL blog.
- OpenSSL 1.1.1 is out of support in September 2023
- Node.js 16 uses OpenSSL 1.1.1 and so will be vulnerable to any exploits discovered after that date, therefore we are terminating the support for Node.js 16 at that time to avoid using an unsupported OpenSSL which would be vulnerable to any discovered exploits in the openssl codebase.
Hold on, I think we're talking about two different things - I was asking why OpenSSL would be a concern for providing functional NodeJS 18 builds for older distros.
Looks like I misread your statement here, my bad:
And of course security (openssl in particular) is precisely why we had to make the unpopular decision to pull forward the support date for Node.js 16. Any of the alternatives would likely have cause far more problems.
I would say some alternatives are statically linking glibc as previously discussed or keeping the old build system alive. The vast majority of distros affected by the lost support for NodeJS 18 aren't near their EoL yet.
I was asking why OpenSSL would be a concern for providing functional NodeJS 18 builds for older distros.
OpenSSL is not a concern for Node.js 18 as it uses OpenSSL v3.
I would say some alternatives are statically linking glibc as previously discussed
Ben mentioned likely issues with that in #43246 (comment) - while I haven't personally tried anything like that I would agree that it seems like a risky thing to attempt to do, and would not be consistent with what we have done anywhere else (And would leave us with the additional task of having to keep up to date with any patches for it). I think all of the existing things we statically link in are built from source in the codebase and I'm not sure there's any appetite for doing that for glibc.
or keeping the old build system alive.
As per #42659 (comment) and the earlier comment in this issue at #43246 (comment) the issue with the old build system is that it was CentOS7 and that would go out of support before the Node 18 support date, so we would not wish to use that as a production build system.
On the basis that it is unlikely that the Node.js project would switch the build environment being used to build Node.js 18 the practical solutions here for users of affected systems would be:
- Build your own
- Ask their distribution provider to build it for you
- Suggest it's done in the unofficial builds project where Node.js 18 could potentially be build on a different OS level, but that requires someone to step to to support its continued building in that environment.
https://github.com/bnoordhuis/cracknode - I wrote a tool to make node work with old distros. Download node, then patch it, that's the basic idea.
Looks promising! Anything for aarch64 machines?
Nope, and no immediate plans either. Open to contracting though.
I created a PR for unofficial-builds to add an "old-glibc" variant: nodejs/unofficial-builds#69
Node.js latest version for CentOS 7 (glibc 2.17) https://github.com/sbwml/node-latest-centos
@richardlau please attempt the following oneliners on your x64 and arm64 buildservers respectively to prevent linking to functions when not necessary. as long as building nodejs does not consume a library that already links to glibc2.28 then this should lower the requirements back to 2.17. simply execute the sed commands and then build nodejs from scratch.
x64 or arm64 native compilation
# __GLIBC_MINOR__ is used as a feature test macro. Replace it with the
# earliest supported version of glibc 2.17 as was previously the case
sudo sed -i 's|\(#define\s\+__GLIBC_MINOR__\)|\1 17 //|' "/usr/include/features.h"
# fcntl64() was introduced in glibc 2.28. Make sure to use fcntl() instead.
sudo sed -i '{N; s/#ifndef __USE_FILE_OFFSET64\(\nextern int fcntl\)/#if 1\1/}' "/usr/include/fcntl.h"arm64 cross compiling
# __GLIBC_MINOR__ is used as a feature test macro. Replace it with the
# earliest supported version of glibc 2.17 as was previously the case
sudo sed -i 's|\(#define\s\+__GLIBC_MINOR__\)|\1 17 //|' "/usr/aarch64-linux-gnu/include/features.h"
# fcntl64() was introduced in glibc 2.28. Make sure to use fcntl() instead.
sudo sed -i '{N; s/#ifndef __USE_FILE_OFFSET64\(\nextern int fcntl\)/#if 1\1/}' "/usr/aarch64-linux-gnu/include/fcntl.h"also please double check that those filepaths are the same on centos. these are ubuntu's standard paths.
this will have no affect on the libstdc++ version that nodejs is dependent on however it is already low enough to be compatible with ubuntu bionic on x64/arm64 libstdc++ >= 6.0.25 (GLIBCXX_3.4.25).
@richardlau see above message please.
Unfortunately I can't help you out any more than this since your build scripts and system images/containers are all closed source 😔
I was redirected here by another conversation. Not sure if this is the appropriate forum so apologies if not.
Given that ubuntu 18 is very much a supported version and node is meant to be supporting supported software, I would say this should be a priority. Failing that, there should be either some restrictions / build failures that indicate this software is no longer supported, alongside some form of article/press release stating that node won't support ubuntu 18 and below.
Migrating a piece of software mid-cadence from supported to unsupported with little to no documentation is why you're seeing huge threads popping up with lots of discussion. Node identifies with following semver, so ideally it needs to pick a camp.
Obviously it's well within the rights of maintainers to support whatever versions they so desire. But if you're going to change things, please articulate why so people can follow / adapt / fix. This is part of the reason I'm a lot more apprehensive with JS packages compared to other languages because of the propensity for these large changes happening with little-no notice.
@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
I'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: version GLIBC_2.27' not found (required by node) node: /lib64/libc.so.6: version GLIBC_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: version GLIBC_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: version GLIBC_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.
@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
@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
@OneCodeMonkey 没办法，谁叫咱要用他们的东西，所以要摆脱依赖
Use Node.js no GCC depends version can solved this problem:
https://www.javaai.org/a/c892d1e98fd94a64018ff4a88ec9000c
@javaaiorg Get。太牛了，没有GCC也能用nodered，长见识了，十分感谢。