Binaries for sunos do not work on Solaris 11.2 - 'GLIBCXX_3.4.20' not found

[GeorgeBailey]

We're increasing our use of Solaris 11.2 X86. The only snag right now is staying compatible with the latest Node.JS releases.

wget http://nodejs.org/dist/v4.2.0/node-v4.2.0-sunos-x64.tar.gz
tar xoZf node-v4.2.0-sunos-x64.tar.gz
node-v4.2.0-sunos-x64/bin/node

I get this for both x86 and x64 binaries.

ld.so.1: node: fatal: libstdc++.so.6: version 'GLIBCXX_3.4.20' not found (required by file node-v4.2.0-sunos-x64/bin/node)
ld.so.1: node: fatal: libstdc++.so.6: open failed: No such file or directory
Killed

Edit: We can now readily build from src on Solaris 11.2 with minor tweaks after downloading v4.2.1.

This issue should now only reference the desire of a pre-compiled that is compatible with Solaris 11.2.

[mscdex]

/cc @nodejs/platform-solaris

[alexijs]

It may not be the best solution, however you can tell the runtime linker to ignore the shared library versions.

SunOS prod 5.11 11.2 i86pc i386 i86pc

IT DOES SIMPLY START IT AND NOT ALLOWING NETWORK/SOCKET CONNECTIONS

[GeorgeBailey]

I can confirm that adding LD_NOVERSION=1 at runtime as @alexijs suggested allows startup, but results in EPROTOTYPE error on TCP or UNIX socket functions. (I did successfully use child processes, crypto.randomBytes.)

Referring to my previous issue, I was getting EPROTOTYPE in v0.12 pre-built binaries as well. This was resolved by cgalibern in a fork. (though I was still getting ECONNREFUSED on outbound TCP)

I wonder whether the same change would resolve EPROTOTYPE in v4.2.0 or if it is a different issue entirely.

[GeorgeBailey]

On mine, I used pkg install gcc which through the dependency tree includes gnu-binutils and I believe it also includes gnu-make. I don't know which compiler is the best to use, but what I really want is to be compatible with both Solaris 10 and Solaris 11. :-)

I don't know what Solaris 10 compatibility would entail, so let's just get Solaris 11 compatibility for now.

[jbergstroem]

@alexijs: CC=/usr/bin/gcc ./configure should work fine if you want to switch compiler

[misterdjules]

There are two different categories of problems mentioned in this issue:

1. Running the binaries downloaded from nodejs.org on Oracle Solaris is not possible due to the proper version of the C++ runtime library not found (the 'GLIBCXX_3.4.20' not found message).
2. Building nodejs/node's master and v4.x from source doesn't work on Oracle Solaris.

2. is tracked with node compile failure on Solaris 11.2 and gcc 4.8 (undefined std::isnan) #3179, so please comment in that issue for any problem related to building node on Solaris.

It would be great if we could also solve 1). Let's see what happens on SmartOS.

SmartOS packages for node v4.x require a C++ runtime at version GLIBCXX_3.4.15:

[root@dev ~]# pvs `which node`
        libkstat.so.1 (SUNW_0.7);
        libumem.so.1 (SUNW_1.1);
        libsocket.so.1 (SUNW_1.7);
        libnsl.so.1 (SUNW_1.7, SUNWprivate_1.1);
        librt.so.1 (SUNW_1.4);
        libsendfile.so.1 (SUNW_1.1);
        libstdc++.so.6 (GLIBCXX_3.4.15, CXXABI_1.3);
        libm.so.2 (SUNW_1.2);
        libgcc_s.so.1 (GCC_3.0);
        libpthread.so.1 (SUNW_1.2);
        libc.so.1 (SUNW_1.23, SUNWprivate_1.1);
[root@dev ~]#

This is definitely older than GLIBCXX_3.4.20, so it has higher chances to run on more systems. The node binary links against /opt/local/gcc48/x86_64-sun-solaris2.11/lib/amd64/libstdc++.so.6, and not against /usr/lib/libstdc++.so.6:

[root@dev ~]# ldd `which node`
        libz.so.1 =>     /opt/local/lib/libz.so.1
        libkstat.so.1 =>         /lib/64/libkstat.so.1
        libumem.so.1 =>  /lib/64/libumem.so.1
        libsocket.so.1 =>        /lib/64/libsocket.so.1
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        librt.so.1 =>    /lib/64/librt.so.1
        libsendfile.so.1 =>      /lib/64/libsendfile.so.1
        libstdc++.so.6 =>        /opt/local/gcc48/x86_64-sun-solaris2.11/lib/amd64/libstdc++.so.6
        libm.so.2 =>     /lib/64/libm.so.2
        libgcc_s.so.1 =>         /opt/local/gcc48/x86_64-sun-solaris2.11/lib/amd64/libgcc_s.so.1
        libpthread.so.1 =>       /lib/64/libpthread.so.1
        libc.so.1 =>     /lib/64/libc.so.1
        libgcc_s.so.1 =>         /opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64/libgcc_s.so.1
        libmp.so.2 =>    /lib/64/libmp.so.2
        libmd.so.1 =>    /lib/64/libmd.so.1
[root@dev ~]#

And that C++ runtime is compatible with version GLIBCXX_3.4.15:

[root@dev ~]# nm /opt/local/gcc48/x86_64-sun-solaris2.11/lib/libstdc++.so.6.0.19 | grep GLIBCXX | grep 3.4.15
00000000 A GLIBCXX_3.4.15
[root@dev ~]#

I don't know yet what makes the pkgsrc packages on SmartOS link with that specific version of libstdc++ and not the default one, I'd need to investigate further.

And finally, SmartOS pkgsrc packages specifically use GCC 4.8 to build the node binary, whereas it seems that the Node.js release jobs use GCC 4.9.1. This helps make the resulting node binary require an older C++ runtime version.

In other words, it is very likely that the Node.js release jobs could make the resulting node binaries link against an older C++ runtime, which could make these binaries run on Oracle Solaris 11.2 by default.

Just to give more context, at some point a similar issue was encountered for Linux binaries distributed by nodejs.org. To work around this problem, Linux node binaries released on nodejs.org use the RedHat developer toolset to link against a specific C++ runtime that includes a static part with newer C++ symbols so that the dynamic part of the C++ runtime can be found on older system, and the node binary can use newer C++ features by including them directly in the binary.

Unfortunately I don't have a Solaris setup at hand, and that makes testing these theories and possible fixes difficult, if not impossible. But that's a starting point for anyone who would be willing to tackle that problem. I might get some time to work on that in the future, in which case I'll keep you posted.

[alexijs]

@jbergstroem: this should work. However, I believe, it gotta be lower case cc.
I relinked them back to solarisstudio compilers (I build apache and php using them and solaris optimization flags without a problem)

[misterdjules]

I don't know yet what makes the pkgsrc packages on SmartOS link with that specific version of libstdc++ and not the default one, I'd need to investigate further.

Actually, just using the GCC 4.8 found in SmartOS pkgsrc packages make the binary link against /opt/local/gcc48/x86_64-sun-solaris2.11/lib/libstdc++.so.6.0.19.

[misterdjules]

@GeorgeBailey Also, the --without-mdb configuration option is not present in node v4.x and later. mdb_v8 is not bundled with node v4.x and later, because bundling the mdb_v8 debugger module in the node binary is actually not useful (it was at some point). Instead, the recommended way to use it is to download the latest release.

[GeorgeBailey]

Have you compiled it successfully via gnu utils?

@alexijs, I was able to compile v0.12, but not v4.2.0.

There are two different categories of problems mentioned in this issue:

@misterdjules, I will start using #3179 for issues building. (your # 1) It makes sense to keep this separate.

So this issue should only be for Solaris 11.2 compatibility with pre-built binaries.

An idea - it would be relevant to know what build environment is used. Is there a wiki on this, so that another person could recreate the build environment on their own?

[misterdjules]

An idea - it would be relevant to know what build environment is used. Is there a wiki on this, so that another person could recreate the build environment on their own?

Definitely. The nodejs/build repository already has some (possibly outdated) documentation. I'm wondering if the best documentation in this case is the source, for instance: https://github.com/nodejs/build/blob/master/setup/smartos/ansible-vars.yaml.

[misterdjules]

@GeorgeBailey @jbergstroem Speaking of https://github.com/nodejs/build/blob/master/setup/smartos/ansible-vars.yaml, I would start investigating replacing gcc49 and gcc49-libs by gcc48 and gcc48-libs and see what impact it has on the C++ runtime that the node binary links to. Chances are that such a binary would work on Solaris 11.2.