Node.js 8.3.0 for CentOS 6 has glibc dependency errors

[danlange]

• Version: 8.3.0
• Platform:Linux automation-reporting 2.6.32-696.6.3.el6.x86_64 deps: update openssl to 1.0.1j #1 SMP Wed Jul 12 14:17:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
• Subsystem:

I installed node on my system:

% curl --silent --location https://rpm.nodesource.com/setup_8.x | sudo bash -
% sudo yum -y install nodejs

When I attempted to use it, it reported shared library errors:

% npm --version
node: error while loading shared libraries: cannot allocate memory in static TLS block
% node --version
node: error while loading shared libraries: cannot allocate memory in static TLS block

I am running CentOS 6, on which the only glibc option is 2.12:

% ldd --version
ldd (GNU libc) 2.12
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

I was able to work around the problem by removing version 8.3.0 and installing version 8.2.1 instead:

% yum remove nodejs
...
% yum -y install nodejs-8.2.1
% npm --version
5.3.0

[addaleax]

Can you confirm that this also happens with the binaries made available on https://nodejs.org/?

[danlange]

It does not appear to. I was able to download and untar: https://nodejs.org/dist/v8.3.0/node-v8.3.0-linux-x64.tar.xz
When I ran it, it appeared to work correctly:

% ./node --version
v8.3.0
% ./npm --version
5.3.0

[mscdex]

This should probably be reported on the nodesource/distributions issue tracker instead.

[danlange]

Ok, I'll report it there.

[evantorrie]

Note: I know this is closed, but we also had the same problem when building from source on RHEL6. We pinpointed root cause down to a bug in all versions of glibc earlier than glibc-2.17 in how Thread-Local-Offset static storage is handled. Specifically, this bug https://sourceware.org/bugzilla/show_bug.cgi?id=14898.

I did download the version from https://nodejs.org/dist/v8.3.0/node-v8.3.0-linux-x64.tar.xz and can confirm that it does work on a RHEL6 machine, even though it also appears that the final node binary has a TLS segment size of just 1 (can be determined by running readelf -l node and looking for the TLS section).

The 1 byte TLS storage was introduced in v8 v6.0 here:

node/deps/v8/src/trap-handler/handler-shared.cc

Line 26 in 2db2857

THREAD_LOCAL bool g_thread_in_wasm_code = false;

[refack]

@evantorrie This seems related nodejs/build#809 (comment). Hopefully when this lands and is gets backported, you could verify.

[evantorrie]

Yes, it's the same issue. In our case, I just patched the v8 source with

diff --git a/deps/v8/src/trap-handler/handler-shared.cc b/deps/v8/src/trap-handler/handler-shared.cc
index 7b399f5..812e797 100644
--- a/deps/v8/src/trap-handler/handler-shared.cc
+++ b/deps/v8/src/trap-handler/handler-shared.cc
@@ -24,6 +24,9 @@ namespace internal{
 namespace trap_handler{
 
 THREAD_LOCAL bool g_thread_in_wasm_code = false;
+#if !__GLIBC_PREREQ(2,17)
+THREAD_LOCAL bool dummy_shared = 0;
+#endif
 
 size_t gNumCodeObjects = 0;
 CodeProtectionInfoListEntry* gCodeObjects = nullptr;

which solved the issue for us internally.

[refack]

So this has landed in an improved form in master

node/deps/v8/src/trap-handler/handler-shared.cc

Lines 26 to 29 in a4e923f

	// We declare this as int rather than bool as a workaround for a glibc bug, in
	// which the dynamic loader cannot handle executables whose TLS area is only
	// 1 byte in size; see https://sourceware.org/bugzilla/show_bug.cgi?id=14898.
	THREAD_LOCAL int g_thread_in_wasm_code = false;

@danlange / @evantorrie you can reopen or comment if you have new information.

[MrunalSolkar12]

@refack I am getting GLIBC_2.16 not found (required by node) while installing the node js in linux and my GLIBC version is 2.12.
If i installed node 8 version does my problem will gets solved?