nodejs Linux clang libc++ no joy?

[ghost]

I was trying to build nodejs 4.6 on Debian squeeze using clang 381
x64. From reading at glance in common.gypi file needs some little hack to adjust ccflags ,ldflags and Icu-generic.gypi also need -frtti ccflags. Unfortunately, configure script need also to be adjusted as well. My temporarily workaround was to tell configure script to generate cmake project file instead of raw makefile. I've tried this and the build stopped at v8 deps. This looked like will happen in freebsd clang as well but I havent tried yet. I 'll diagnosed the problems and post the progress when the time permits.

• Version: node 4.6.0
• Platform: Linux Debian 6
• Subsystem:

[bnoordhuis]

Can you do a clean build and post the verbatim output? If you get RTTI errors, try applying #8886.

[ghost]

I 've applied that, but I don't understand why icu gyp build still pick g++ in my path when I had tell both CC and CXX env to clang and clang++.

[bnoordhuis]

Try building with make CC.host=clang CC.target=clang CXX.host=clang++ CXX.target=clang++ LINK.host=clang++ LINK.target=clang++.

[ghost]

same problem comparing with my former cmake build

make -C out BUILDTYPE=Release V=1
make[1]: Entering directory `/home/user/folder/node-v4.6.0/out'
  clang++ '-DV8_TARGET_ARCH_X64' '-DENABLE_DISASSEMBLER' '-DV8_I18N_SUPPORT' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC' '-DUCONFIG_NO_TRANSLITERATION=1' '-DUCONFIG_NO_SERVICE=1' '-DUCONFIG_NO_REGULAR_EXPRESSIONS=1' '-DU_ENABLE_DYLOAD=0' '-DU_STATIC_IMPLEMENTATION=1' '-DU_HAVE_STD_STRING=0' '-DUCONFIG_NO_BREAK_ITERATION=0' '-DUCONFIG_NO_LEGACY_CONVERSION=1' '-DUCONFIG_NO_IDNA=1' '-DUCONFIG_NO_CONVERSION=1' -I../deps/v8 -I../deps/icu/source/i18n -I../deps/icu/source/common  -pthread -Wall -Wextra -Wno-unused-parameter -m64 -fno-strict-aliasing -m64 -O3 -ffunction-sections -fdata-sections -fno-omit-frame-pointer -fdata-sections -ffunction-sections -O3 -stdlib=libc++ -fno-rtti -fno-exceptions -std=gnu++0x -MMD -MF /home/user/folder/node-v4.6.0/out/Release/.deps//home/user/folder/node-v4.6.0/out/Release/obj.target/v8_base/deps/v8/src/compiler/ast-graph-builder.o.d.raw   -c -o /home/user/folder/node-v4.6.0/out/Release/obj.target/v8_base/deps/v8/src/compiler/ast-graph-builder.o ../deps/v8/src/compiler/ast-graph-builder.cc
In file included from ../deps/v8/src/compiler/ast-graph-builder.cc:5:
In file included from ../deps/v8/src/compiler/ast-graph-builder.h:8:
In file included from ../deps/v8/src/ast.h:8:
In file included from ../deps/v8/src/v8.h:39:
In file included from ../deps/v8/src/objects-inl.h:17:
In file included from ../deps/v8/src/contexts.h:8:
In file included from ../deps/v8/src/heap/heap.h:9:
/home/user/folder/clang38debian6gcc8/bin/../include/c++/v1/map:837:5: error: static_assert failed "Allocator::value_type must be same type as value_type"
    static_assert((is_same<typename allocator_type::value_type, value_type>::value),
    ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../deps/v8/src/compiler/js-type-feedback.h:41:21: note: in instantiation of template class 'std::__1::map<unsigned int, v8::internal::TypeFeedbackId, std::__1::less<unsigned int>, v8::internal::zone_allocator<v8::internal::TypeFeedbackId> >' requested here
  TypeFeedbackIdMap type_feedback_id_map_;
                    ^
In file included from ../deps/v8/src/compiler/ast-graph-builder.cc:5:
In file included from ../deps/v8/src/compiler/ast-graph-builder.h:8:
In file included from ../deps/v8/src/ast.h:8:
In file included from ../deps/v8/src/v8.h:39:
In file included from ../deps/v8/src/objects-inl.h:17:
In file included from ../deps/v8/src/contexts.h:8:
In file included from ../deps/v8/src/heap/heap.h:9:
/home/user/folder/clang38debian6gcc8/bin/../include/c++/v1/map:837:5: error: static_assert failed "Allocator::value_type must be same type as value_type"
    static_assert((is_same<typename allocator_type::value_type, value_type>::value),
    ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../deps/v8/src/compiler/js-type-feedback.h:42:27: note: in instantiation of template class 'std::__1::map<unsigned int, v8::internal::VectorSlot<1>, std::__1::less<unsigned int>, v8::internal::zone_allocator<v8::internal::VectorSlot<1> > >' requested here
  FeedbackVectorICSlotMap feedback_vector_ic_slot_map_;
                          ^
../deps/v8/src/compiler/js-type-feedback.h:45:24: error: no type named 'const_iterator' in 'std::__1::map<unsigned int, v8::internal::TypeFeedbackId, std::__1::less<unsigned int>, v8::internal::zone_allocator<v8::internal::TypeFeedbackId> >'
    TypeFeedbackIdMap::const_iterator it =
    ~~~~~~~~~~~~~~~~~~~^
../deps/v8/src/compiler/js-type-feedback.h:52:30: error: no type named 'const_iterator' in 'std::__1::map<unsigned int, v8::internal::VectorSlot<1>, std::__1::less<unsigned int>, v8::internal::zone_allocator<v8::internal::VectorSlot<1> > >'
    FeedbackVectorICSlotMap::const_iterator it =
    ~~~~~~~~~~~~~~~~~~~~~~~~~^
4 errors generated.
make[1]: *** [/home/user/folder/node-v4.6.0/out/Release/obj.target/v8_base/deps/v8/src/compiler/ast-graph-builder.o] Error 1
make[1]: Leaving directory `/home/user/folder/node-v4.6.0/out'
make: *** [node] Error 2

[ghost]

looked like there was missing PR from nodejs repo and freebsd port , this was long several months ago http://www.freshports.org/www/node

This is because libc++ 3.8.0 has added these sanity checks for custom
std::map allocators, which *must* be of the type std::pair<const Key,
Value>.  I fixed the few std::map instances in the node source by adding
this to their allocator types.

[ghost]

the corresponding patch is here https://bz-attachments.freebsd.org/attachment.cgi?id=168585

[ghost]

Quick solution was to copy v8 deps from 6.x branch to 4.6.x v8 deps.

[bnoordhuis]

Okay, so this is a V8 4.5 build issue that seems to be specific to your combination of compiler/libc++/etc.

If you want to see this fixed, you could try filing a pull request against the v4.x-staging branch. If you are happy with your current workaround, can you close the issue? Thanks.

[ghost]

Yes I will :) , but the configure script still certainly needs some tweaks. whether good if I will be adding new options to the configure script for generic solutions on several differences clang compiler options ccflags and ldflags. Such as this may happen the user can compile with lisbstdc++ mode clang, libc++ libcxxrt and libc++abi so of course this will affect ldflags. And I'm not sure if clang static linking is possible except for libstdc++ and optionally tweaking LD_LIBRARY_PATH or adding -rpath option for convenient make test or make install. Any thought?

[bnoordhuis]

We'd have to thoroughly research what the ramifications of statically linking libc++ et al. would be.

For example, a node binary linked against one libc++ version trying to interact with a native module linked against another libc++ version could end catastrophically because of incompatible memory allocators and such.

[ghost]

@bnoordhuis, sorry I couldn't afford fast internet connection this week, I'll send my complete patch for clang support to your mail, I hope you could review and forward it to upstram pull request. I'm closing this issue now.
Thank you.