Provide C++ ABI version to addons

[saper]

Some platforms (most notably FreeBSD, MacOSX) use gcc or clang interchangeably. We no longer support compiler identification (#205), but what is needed for addons is know know which C++ library node has been compiled against.

At node-sass (https://github.com/sass/node-sass/blob/043c56705c663977468551206556d7f3c75ef9c1/src/libsass.gyp#L68) we were using --stdlib=libc++ clang option to force the use of Clang's C++ library but that is probably incorrect as this causes issues with node engines compiled against GNU libstc++.so.6. (Example: fsevents/fsevents#82).

FreeBSD 9 uses oldish GCC (4.2.1 by default) and we need to use some newer add-on compiler to get a decent C++11 support. But we don't know if the user compiles node with libstdc++.so.6 from gcc 4.8, 4.9 or maybe 5.0, or maybe with clang and links against its libc++.

It would be idea if C++ ABI information made its way into config.gypi and into the process.config variable.
We would love to be able to provide different binary modules for different C++ library configurations (sass/node-sass#733).

Some additional links for reference:

• GNU stdlibc++ ABI Policy and Guidelines
• GNU stdlibc++ 5.1 Dual ABI
• LLVM "libc++" C++ Standard Library

[bnoordhuis]

I think what you're asking for is not the ABI version (that's basically the name mangling scheme, controlled by -fabi-version=) but a flag that tells you what stdlib the node binary is linked against?

I don't think we can help you there. Node doesn't really know, it doesn't use -stdlib= (which is clang-only AFAIK), and what's more, users can always override the actual library at run-time.

[bnoordhuis]

Closing due to inactivity.

[saper]

You can't switch C++ runtime without very bad consequences (in 99% cases it won't work at all) - that's the point of this bug...

I have a concrete example which hit us very badly (sass/node-sass#1283). I have a preliminary patch to make sure we always use single ABI on Windows, and do not compile addons with a C++ ABI that is different than the one the node engine itself is using. They need to be compatible (in C++ world this means: the same).

[bnoordhuis]

Are there any concrete suggestions for improvement you can make? I closed the issue because I don't see a good way of implementing what you're asking for. It's possible I misunderstand the nature of the feature request, of course.

You can't switch C++ runtime without very bad consequences (in 99% cases it won't work at all) - that's the point of this bug...

Switching from libc++ to libstdc++ or vice versa will probably fail badly, yes. Switching from one copy of libc++ or libstdc++ to another in most cases works fine, though.

In #2576 (comment), what I'm saying is that node can't do much better than poorly duplicating ldd node or parsing /proc/self/maps (which isn't portable.)

[saper]

I think I have misstated what I meant. No magic detection of the ABI used is possible, what is merely needed is to expose the ABI used to compile the node engine itself in the exported gypi files. Think of exporting some additional C++ compiler and linker flags.

For example for Microsoft Windows this should be PlatformToolkit version variable set to v120. For MacOS X we should be setting -stdlib= and also expose this value for node-gyp modules.

I'll propose a Windows patch first so hopefully it will be more clear.