_ZNKSt9type_infoeqERKS_ not found with gcc 6.3.0.1 on AIX 7.1

[a4amitava]

Hi - Is there any document or reference to install npm on AIX system ?
Please help to provide any reference on How to install and configure Node on AIX .

---

EDIT(gibfahn):

The help issue () uncovered an issue with our builds, namely that they don't work with the libstdc++ from gcc 6.3.0.1 (reproduced by @shellberg). I'm reopening this, and adding the relevant information from that issue.

$ node - v
exec(): 0509-036 Cannot load program node because of the following errors:
        0509-130 Symbol resolution failed for node because:
        0509-136   Symbol _ZNKSt9type_infoeqERKS_ (number 345) is not exported from
                   dependent module /opt/freeware/lib/pthread/ppc64/libstdc++.a[libstdc++.so.6].
        0509-192 Examine .loader section symbols with the
                 'dump -Tv' command.

$ g++ --version 
gcc version 6.3.0 (GCC)

$ rpm -qa | grep c++ 
libstdc++-devel-6.3.0-1.ppc
libstdc++-6.3.0-1.ppc
gcc-c++-6.3.0-1.ppc

[gireeshpunathil]

@a4amitava - there is no special instructions for AIX, it follows a simple unzipping the package and setting the path sequence. For example, you could:

1. Download latest installer
2. Uncompress into a convenient folder
3. export your PATH variable to the bin folder under the unzipped one.

and start using node and npm.

Please let me know if you found any difficulty.

[gibfahn]

@a4amitava for example

installdir="$HOME/node" # Use whatever path you'd like to install to
curl https://nodejs.org/dist/v6.11.2/node-v6.11.2-aix-ppc64.tar.gz | tar -xf --directory $installdir --strip-components 1
export PATH="$installdir/bin:$PATH" # Add this to your ~/.bashrc to make it permanent.

This will put the bin/ directory in /home/youruser/node/bin, and add it to the $PATH. You can verify that it worked with:

node --version
npm --version

You can extract the tarball anywhere, just make sure you add the bin/ directory to the path.

[gibfahn]

Questions like this are normally better suited for nodejs/help. I'll close this as answered, but feel free to comment or reopen if you have further questions.

[a4amitava]

Below error encountered when we execute the node cmd -- Can you pls help ?

exec(): 0509-036 Cannot load program node because of the following errors:
        0509-130 Symbol resolution failed for node because:
        0509-136   Symbol _ZNKSt9type_infoeqERKS_ (number 345) is not exported from
                   dependent module /opt/freeware/lib/pthread/ppc64/libstdc++.a[libstdc++.so.6].
        0509-192 Examine .loader section symbols with the
                 'dump -Tv' command.

[gibfahn]

@a4amitava so @gireeshpunathil and @shellberg are the experts here, but I can tell you what I know.

You need at least gcc4.8.4, and the libstdc++.a version that comes with it, to run Node. We have it installed in /usr/local/gcc-4.8.4-1/. To run node we need to set the LIBPATH variable, which we do as follows:

export LIBPATH=/usr/local/gcc-4.8.4-1/lib/gcc/powerpc-ibm-aix6.1.0.0/4.8.4/pthread/ppc64

Hopefully you can do the equivalent on your system.

If you have any more issues, can you first tell us what version of AIX you're running, and what version of Node you're trying to install?

cc/ @nodejs/platform-aix

[gibfahn]

I see that @shellberg already answered your question in nodejs/help#784, so let's continue the conversation there.

[a4amitava]

@gireeshpunathil .
I have followed you , but getting the below error . i have also posted the same to help forum nodejs/help#784
Can you please also advice ?

node - v
exec(): 0509-036 Cannot load program node because of the following errors:
0509-130 Symbol resolution failed for node because:
0509-136 Symbol ZNKSt9type_infoeqERKS (number 345) is not exported from
dependent module /opt/freeware/lib/pthread/ppc64/libstdc++.a[libstdc++.so.6].
0509-192 Examine .loader section symbols with the
'dump -Tv' command.

[gibfahn]

Suggestion from @bnoordhuis:

sounds like node was compiled with type info (-frtti flag)

@shellberg FYI.

[shellberg]

Thanks @gib / @bnoordhuis.

Compiling with -frtti is the default for gcc / g++, and for the majority (all?) of other mainstream compilers. Consequently, to produce a binary for node without RTTI support introduces a potential issue for any other native module implementations that derive from libuv or v8 classes/structs. I'm unclear yet whether our node implementation relies upon runtime type info (crankshaft / TF?) at all, or is benign in performance and functional terms....

[bnoordhuis]

Hi @shellberg, node.js and its dependencies (V8, libuv, etc.) are built with -fno-rtti -fno-exceptions.

Add-ons (native modules) can decide for themselves whether to enable RTTI or exceptions or not. Interoperability is seamless as long as you don't let exceptions bubble up into -fno-rtti code.

[gibfahn]

@bnoordhuis given this error (with the community AIX build of Node), that suggests that we're not using that flag on AIX right? Where is it set in other platforms?

[gibfahn]

Okay, answered my own question, we set -fno-rtti for AIX in common.gypi for node, and things in deps/:

• Node:

node/common.gypi

Lines 273 to 275 in e70d0b0

	[ 'OS in "linux freebsd openbsd solaris android aix"', {
	'cflags': [ '-Wall', '-Wextra', '-Wno-unused-parameter', ],
	'cflags_cc': [ '-fno-rtti', '-fno-exceptions', '-std=gnu++0x' ],

• c-ares:

node/deps/cares/common.gypi

Lines 140 to 145 in e70d0b0

	[ 'OS in "linux freebsd openbsd solaris android aix"', {
	'variables': {
	'gcc_version%': '<!(python build/gcc_version.py)>)'
	},
	'cflags': [ '-Wall' ],
	'cflags_cc': [ '-fno-rtti', '-fno-exceptions' ],

• V8:

node/deps/v8/build/standalone.gypi

Lines 687 to 704 in e70d0b0

	['OS=="linux" or OS=="freebsd" or OS=="openbsd" or OS=="solaris" \
	or OS=="netbsd" or OS=="aix"', {
	'target_defaults': {
	'cflags': [
	'-Wall',
	'<(werror)',
	'-Wno-unused-parameter',
	'-Wno-long-long',
	'-pthread',
	'-pedantic',
	# Don't warn about the "struct foo f = {0};" initialization pattern.
	'-Wno-missing-field-initializers',
	'-Wno-gnu-zero-variadic-macro-arguments',
	],
	'cflags_cc': [
	'-Wnon-virtual-dtor',
	'-fno-exceptions',
	'-fno-rtti',

However I note that ICU is built with -frtti, see this PR by Ben: #8886

Also libuv doesn't seem to have an option for AIX, maybe an oversight (I feel like it should be here):

node/deps/uv/common.gypi

Lines 130 to 132 in e70d0b0

	['OS in "freebsd dragonflybsd linux openbsd solaris android"', {
	'cflags': [ '-Wall' ],
	'cflags_cc': [ '-fno-rtti', '-fno-exceptions' ],

So I guess the question is where this error is coming from.

[shellberg]

Thanks Ben (@bnoordhuis ). We've clearly stumbled into inconsistency that we hadn't intended in producing the node binary builds on AIX.
@gib : Looks like we have a few places in which to restore consistency... Although, the ICU component alone, being built with RTTI would seem to have the potential for 'tickling' this issue in the future. But, for now, the libuv component would be the likely candidate given 'aix' is not present in its common.gypi.

[bnoordhuis]

@shellberg cflags_cc are C++ compiler flags but libuv is a C project, it only uses cflags.

The fact that cflags_cc is in libuv's common.gypi is a vestigial artifact of copying node's common.gypi when we started on libuv.

[gibfahn]

@bnoordhuis so any thoughts on where this flag could be coming in? Is it likely to be in ICU? If so it sounds like we can't turn it off.

[bnoordhuis]

@gibson grep -r frtti out/ should tell you but ICU seems like the most likely candidate.

[gibfahn]

Okay, grep -r frtti out/ gives lots of results, grep -r frtti out/ | grep -v icu returns no results. Seems pretty clear.

[srl295]

RTTI is needed for ICU’s own processing. It can be turned off in any client code, though. (No caller is required to make use of RTTI in order to use ICU.) This is since ICU 4.6, some 8 years ago https://ssl.icu-project.org/trac/ticket/7455 — as an aside, ICU is now a C++-only project (for its implementation code)

[bnoordhuis]

Can this be closed now that #15286 was merged?

[shellberg]

#15286 brings in -brtl into the master stream and into a future semver-major release...

This reported issue, however, has highlighted an AIX incompatibility that arises on the GNU libstdc++ v5 boundary, and which currently affects all current node LTS releases and the way they are currently being built. AIX linkage model is raising some uncomfortable restrictions that mean forward compatibility is compromised on AIX in how the GNU community chose how to handle full C++2011 and C++2014 support... And, with potential ramifactions for diagnostic and debugging tooling too (the GNU tooling distributed in AIX would not have support for the v5 dual namespace that was introduced for symbols).

I'd prefer to keep this open as an issue as we (at least myself, @gireeshpunathil and @gib) work towards deciding what to best recommend for the AIX platform in the timescale of version 8 going LTS. I'm leaning towards suggesting re-basing minimum libstdc++ support to 6.3.0, which bakes in C++2011 and C++2014 full support buying some future proofing against v8 adoption of C++2014 features, but that also compels all AIX installations to have to add that level of libstdc++ support to use node
(only AIX 7.2 presently distributes GNU C++ runtime support at 4.8.4), and potentially upgrade more tooling to diagnose any future failures.

[gibfahn]

Can this be closed now that #15286 was merged?

Short answer is no, that was a different issue.

[gireeshpunathil]

@a4amitava - latest Node (v10.x) is built with gcc 6.3.x so should work fine for you now. Can you please check and confirm?

[gireeshpunathil]

no response, closing. As we know, the issue is actually fixed in Node v10.x (thought it would have been good if someone from the field verifying it)

[shellberg]

FYI : Node 11 dependencies are still based on employing the GNU compiler toolchain v6.3, and #1595 documents the set of freeware additions needed to be added to a clean AIX 7.1 base installation to meet this requirement.

[gireeshpunathil]

just wondering whether we should document this here . thoughts?