Repository navigation
Provide C++ ABI version to addons #2576
Description
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:
Activity
bnoordhuis commentedon Aug 27, 2015
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 commentedon Feb 12, 2016
Closing due to inactivity.
saper commentedon Feb 12, 2016
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 commentedon Feb 12, 2016
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.
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 nodeor parsing/proc/self/maps(which isn't portable.)saper commentedon Feb 14, 2016
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
gypifiles. Think of exporting some additional C++ compiler and linker flags.For example for Microsoft Windows this should be
PlatformToolkitversion variable set tov120. For MacOS X we should be setting-stdlib=and also expose this value fornode-gypmodules.I'll propose a Windows patch first so hopefully it will be more clear.