Allow building with libc++

[deanm]

On OSX, the new STL library is libc++:

http://libcxx.llvm.org/

In order to build Node and V8 using libc++, the -stdlib flag has to be plumbed through the build system.

Gyp needs to be updated to include the fix for CLANG_CXX_LIBRARY:

https://code.google.com/p/gyp/source/detail?spec=svn1948&r=1921

And then the configure system needs a way of specifying the value for CLANG_CXX_LIBRARY so it can be set to libc++

There are some benefits to using libc++ (performance/memory), and it will have to happen eventually if any of the C++11 features are used anywhere in the project. Would be very nice to have.

[indutny]

Hm... we are not really going to use C++11 features anywhere soon.

What benefits will it really give us? Any benchmark improvements? Could you please paste some results?

[deanm]

These are exactly the sort of questions you can answer by easily changing which standard library is being used. I am not suggesting that Node necessarily move to libc++ by default, but there is where things are headed in general. From the Xcode 4.5 release notes:

https://developer.apple.com/library/ios/releasenotes/developertools/rn-xcode/xc4_release_notes/xc4_release_notes.html#//apple_ref/doc/uid/TP40001051-CH3-SW174

Projects created using this Xcode release use the new libc++ implementation of the standard C++ library. The libc++ library is available only on iOS 5.0 and later and OS X 10.7 and later. 12221787
To enable deployment on earlier releases of iOS and OS X in your project, set the C++ Standard Library build setting to libstdc++ (Gnu C++ standard library).

The point being there are pros and cons on both sides, and cases for ABI compatibility where you want to choose to use one or the other. Since OSX is switching over to libc++ (I will imagine the default for llvm builds will change too, if it hasn't already), I think it is good to have the option to select libstdc++ or libc++ through Node's build system.

[indutny]

Summoning @bnoordhuis here. I'm definitely -1 on this myself, it seems just unnecessary.

[deanm]

I feel like you want me to sell it to you, which I am not going to try to do. Apple has decided to make it the default, and the LLVM people seem to think it is "better" than libstdc++ and that people should use it.

Specifically they (LLVM) seem to think it is superior in many ways, even for non C++11 code. They have for example changed how std::string is implemented, and in many cases seem to think it performs better and uses less memory. There are some old slides available at:

http://llvm.org/devmtg/2010-11/Hinnant-libcxx.pdf

I don't really mind if you decide it is "unnecessary", I just wanted to point out that the rest of the OSX world is moving to libc++ and they feel that it is better, and right now it's not very easy to build Node using libc++, and a few small changes would make it easy.

[indutny]

@deanm the reason is that the only thing that we do really use from C++ is classes and virtual methods. We do not use std:: much, and not going to.

Guess there is no point for us to update if we are not going to use it.

[deanm]

Yes, but the choice also affects how V8 is built, which does use the stl and things like std::sort.

Also there are some recent changes to V8 for things like supporting move semantics (UniquePersistent). Which means if you want to be able to use those in a Node module you will need to support C++11.

I would say you could at least update Gyp to get the fix for CLANG_CXX_LIBRARY, then we can just edit the build files.

[deanm]

Filed #7924 for the gyp update.

[bnoordhuis]

I don't really object to updating gyp or making it possible to link to libc++ as long as there's no expectation of support. I suspect there's an ulterior motive here in that @deanm probably wants to embed node.js in another project but that's fine by me. :-)

As to C++11, I would like to move to it sometime but VS 2010 is still our semi-official baseline (I think) so there's little chance of that happening for now. That means libc++ has little compelling features for this project but on the other hand, if we can make life a little easier for embedders, then I don't see why not.

[jbergstroem]

Supporting different implementations of a standard library (at least exposing the build ecosystem to them) should be supported, much the same way you can user whatever compiler you prefer in my opinion. The choice whether to use newer language standard seems irrelevant to that regard.

[DomT4]

Going to bump this old issue and file a request the Node team reconsider the decision made in this issue. Not supporting libc++ is causing packaging issues against icu4c which is supported in the latest v0.12 release - In some situations, downstream package managers are struggling to support that configuration because of Node's default deployment target being rather... old. It would make life a lot easier in terms of packaging Node if there was at least the option to switch the deployment target.

See: Homebrew/legacy-homebrew#36681

[srl295]

@DomT4 hi again. missed this one completely until it bit me on a mac development.
The v8 issue linked has been closed, has it landed in node?
What is the "option to switch deployment target" you are looking for?

[DomT4]

Hi @srl295 - Sorry, this got buried when I reorganised my inbox recently to filter Github emails into a special folder.

I'm not sure on the V8 front to be honest. It looks like it could be the v8 elements still building against libstdc++ rather than libc++ but don't quote me on that.

Homebrew's issue is that we'd like to enable icu4c by default for the ICU support, but because Node or something within Node builds against libstdc++ and icu4c builds against libc++ there's a deployment target clash there. We ended up having to revert recommended ICU support for Node because of this report where the two combined broke at least Titanium.

We'd like to offer more full ICU support once again, but doing so seems to hinge on Node building against, or at least having an option to build against, libc++ on modern OS X versions.