recent v18.0.0 nightly builds require GLIBC_2.28

[trentm]

Version

v18.0.0-nightly20220315a01302b8df

Platform

Linux 5d282713443e 5.10.76-linuxkit #1 SMP Mon Nov 8 10:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

Attempt to run a recent node v18.0.0 nightly (e.g. https://nodejs.org/download/nightly/v18.0.0-nightly20220315a01302b8df/) on Ubuntu 18.04 or earlier.

% docker run -ti --rm ubuntu:18.04 /bin/bash
root@5d282713443e:/# apt-get -qq update && apt-get -qq install -y curl
...
root@5d282713443e:/# curl -O https://nodejs.org/download/nightly/v18.0.0-nightly20220315a01302b8df/node-v18.0.0-nightly20220315a01302b8df-linux-x64.tar.gz
...
root@5d282713443e:/# tar xf node-v18.0.0-nightly20220315a01302b8df-linux-x64.tar.gz
root@5d282713443e:/# ./node-v18.0.0-nightly20220315a01302b8df-linux-x64/bin/node
./node-v18.0.0-nightly20220315a01302b8df-linux-x64/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by ./node-v18.0.0-nightly20220315a01302b8df-linux-x64/bin/node)

Ubuntu 18.04 only has glibc 2.27:

root@5d282713443e:/# /lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Ubuntu GLIBC 2.27-3ubuntu1.5) stable release version 2.27.

I haven't worked backwards to find out which nightly build introduced this. I can do so if that would help.

How often does it reproduce? Is there a required condition?

Reproduces every time on Ubuntu 18.04.

What is the expected behavior?

Nightly builds of v18.0.0 from a week or two ago (last I checked) ran fine on Ubuntu 18.04. My expectation is that nightly builds would continue to do so. However, I don't know what the policy is for supported Linux glibc. The building notes (https://github.com/nodejs/node/blob/master/BUILDING.md#platform-list) suggest glibc >2.17 should suffice for building.

Did something change in how the node.js nightlies are being built? Was this change to a newer minimum glibc version intentional? (Apologies if this is the wrong place to ask.)

What do you see instead?

Node crashes.

Additional information

No response

[richardlau]

This is intentional -- we're moving compilation of Node.js binaries from CentOS 7 to RHEL 8 for Node.js 18. I'll be opening an update to https://github.com/nodejs/node/blob/master/BUILDING.md#platform-list later in the week. Unfortunately, as you have discovered, this includes a glibc version bump that excludes Ubuntu 18.04 (18.10 and 20.04 should work).

[trentm]

@richardlau Okay. Thanks for the info!

[grahamb]

It looks like this means that Node 18 doesn't run on RHEL 7 either?

❯ nvm install 18.3.0
Downloading and installing node v18.3.0...
Downloading https://nodejs.org/dist/v18.3.0/node-v18.3.0-linux-x64.tar.xz...
######################################################################## 100.0%
Computing checksum with sha256sum
Checksums matched!
Now using node v18.3.0 (npm v)

❯ nvm use 18
Found '/home/grahamb/code/mfa-manager/.nvmrc' with version <18.3.0>
Now using node v18.3.0 (npm v)

❯ node --version
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)
node: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by node)
node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by node)
node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by node)

[bnoordhuis]

@grahamb Correct. More discussion in #43246.

[cabrel92]

unfortunately nodejs 18.4.0 does not support ubuntu 18.04

[JoshMcCullough]

This is a BIG change! I guess it's cool since it's a new major version. :)

[grahamb]

I wouldn't exactly call it "cool", no.

[JoshMcCullough]

Understood and agreed. I had to rework our entire Jenkins setup because RHEL7 has the older GLIBC. Couple days of work on that. But we must upgrade and move forward!

[zedfight]

Modify node version to 16

[Mng12345]

To be honest, it's more and more painful to use nodejs on older linux system for the high version requirement of glibc.

[luke-hill]

For a non-JS expert. Are we saying that 1804 will only run Node16 and not 18? Is there a separate package/workaround?

[bnoordhuis]

You can try https://github.com/bnoordhuis/cracknode - no guarantees but it works for me on x86_64 ubuntu 18.04.

[billyjbryant]

Node16 goes EOL in September, is there seriously no fix for this issue in OVER A YEAR? Does anyone have a solution?

[bnoordhuis]

Yes. One comment up.

[grahamb]

That’s a workaround, not a solution, especially not in a production environment.

[bnoordhuis]

Take it or leave it. Either use it or upgrade your distro, choice is yours.

[sbwml]

Node.js latest version for CentOS 7 (glibc 2.17) https://github.com/sbwml/node-latest-centos

[shingonoide]

This is intentional -- we're moving compilation of Node.js binaries from CentOS 7 to RHEL 8 for Node.js 18. I'll be opening an update to https://github.com/nodejs/node/blob/master/BUILDING.md#platform-list later in the week. Unfortunately, as you have discovered, this includes a glibc version bump that excludes Ubuntu 18.04 (18.10 and 20.04 should work).

@richardlau Thank you for the clarification. I appreciate your update on the intentional decision to move the compilation of Node.js binaries from CentOS 7 to RHEL 8 for Node.js 18, and the associated requirement of GLIBC_2.28 as the Glibc API version. However, I would still like to discuss the necessity of this specific version requirement, especially considering the significant jump from GLIBC_2.17 to GLIBC_2.28.

I believe that understanding the technical justifications behind such a version change would be valuable for the community. Could you please provide me with more detailed information on the technical advantages or specific reasons that led to the selection of GLIBC_2.28 as the required Glibc API version? This would greatly assist in comprehending the implications and benefits of this decision.

Thank you for your time and assistance. I'm looking forward to gaining further insights into this matter.

[bnoordhuis]

@shingonoide see the discussion in #43246

[luke-hill]

I would push for the node maintainers that "all" versions of LTS node going forward should support all versions of LTS ubuntu that are in maintenance windows. That's the dictionary definition of support / supported windows.

Using ubuntu 18.04 is not considered using legacy / outdated software. It's still very much supported, receives regular patches e.t.c.

[bnoordhuis]

You don't get to make that call though. I've been thinking of offering commercial support for people who can't or don't want to upgrade to a supported OS. Get in touch if you're interested.

[luke-hill]

Where / Who would be responsible for making that call? I'll happily divert / push there if needs be.

Commercial support should only be for unsupported versions. i.e. say for Ubuntu 14 or OSX Mojave, that would make sense / the ESR program.

I want to make it clear that you cannot start expecting commercial support for people who are using active versions of software for something that is / was free / in support previously just on a whim. If/when node plan to stop supporting huge chunks of their userbase (Which it is within their rights to do), then I would expect some sort of press release or large scale article articulating why (Whether through effort required or userbase declining e.t.c.)

That then allows people the time to adequately provision themselves, whether that's through a more aggressive update plan on their end, or whether they go down the paid support private route

[bnoordhuis]

To be clear: it's up to the Node.js project to decide where to invest its resources, human or otherwise, and that includes what platforms they will and won't support. You as a user get to voice your opinion but ultimately it's not your call to make.

I (as in me, personally) offer commercial support for things the Node.js project does not. I provide ongoing Node.js v14.x updates (and soon v16.x) for a number of companies and I'm open to maintaining Node.js for platforms that the Node.js project is not willing to support, either by working with upstream, or by providing a custom distribution.

You can find my email in my profile. Reach out if you're interested.

[luke-hill]

I think you've missed the point I was making... Twice. So I won't be commenting any more.

Should you wish to have a reasonable discussion let me know, failing that take my absence of commenting for whatever you will.

[bnoordhuis]

The point you're making is clear, it's just not valid. The change was communicated upfront but even if it wasn't, that still doesn't give you an inalienable entitlement to support. That's what commercial contracts are for.