0.11.15 binary linked against GLIBCXX_3.4.15 breaks centos 6.5 default support

[compcj]

It said gcc 4.2 or above is enough to compile the source, however the published binary linked against GLIBCXX_3.4.15 which is not included in gcc 4.4.7 shipped with Centos 6.5. (Might also breaks CentOS 6.6 as it's also shipped with gcc 4.4.7)
Is it intended? Will this also be true in 0.12 binary?
As CentOS 6.5 is still widely used in production environment, this requires compiling & install newer gcc or node by hand, which adds extra complexity in production environments. Is it possible to add some workaround about this?

[misterdjules]

Currently, Linux binaries are built on CentOS 5.7 with gcc 4.7.3 and g++ 4.7.3, and some code in V8 makes it require a libstdc++ that supports GLIBCXX_3.4.15:

$ nm ./out/Release/node | c++filt | grep GLIBCXX_3.4.15
                 U std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@@GLIBCXX_3.4.15
$ 

I don't think it is "intended", it's probably more that it fell through the cracks.

However, I was able to build node on the same build machine with gcc and g++ 4.4.7-1 with a simple patch. All tests pass and the binary doesn't require a libstdc++ at version GLIBCXX_3.4.15 anymore.

I think we should try to build node binaries with the oldest toolchain possible, as long as it doesn't have a negative impact on the rest of the supported platforms. There are a lot of additional warnings triggered when using older C and C++ compilers though, and I think we would need to fix these before if we were to go down that path.

So my suggestion would be to:

1. Submit a PR with a patch that makes node build with gcc and g++ 4.4.7 on CentOS with all tests passing and no additional warning (or as few as possible).
2. If 1) is successful, change the build jobs to use gcc and g++ 4.4.7 to build Linux binaries.
3. Test that these binaries work as expected on a wide range of Linux platforms.

I'm not sure how that would fit in the current release schedule though, as we're approaching the release of (hopefully) one of the latest release candidates for 0.12.0 and that could potentially break a lot of users on Linux.

[misterdjules]

@compcj Also, node v0.11.15 being a release candidate for node v0.12.0, any issue valid in node v0.11.15 would be valid for node v0.12.0 if not fixed in the meantime.

There will be another release candidate (node v0.11.16) soon that addresses the issues found so far with node v0.11.15. You can find more about it in the 0.11.16 milestone.

[misterdjules]

Added to the 0.11.16 milestone so that we can discuss where it fits regarding the release schedule.

[tjfontaine]

great work @misterdjules -- lets definitely get that landed so we can compile with picky old compilers. If the test suite passes using the binary built from the release infra, on other old distros and other new distros I think we're fairly safe. I think we can just reach out to the community to test to find that information out.

[jbltx]

Any possibilities to compile with g++-4.2.3 ? (In the README it's written GCC 4.2 or newer, but I have doubt about this...)

[misterdjules]

@jbltx That's a good suggestion, thank you! We can at least try and see how it goes and what would be required to fix it.

However, we should keep in mind that the main goal is to be able to run binaries that are downloaded from nodejs.org on the same platforms as v0.10.x, or on as many platforms that were supported by v0.10 as possible. Would building node binaries on Linux with g++ 4.2.3 increase the set of supported platforms? If not, then it might not be worth the effort and we could just change the information in the README.md file.

Also, if you have some time to do that, a PR would be very much appreciated!

[misterdjules]

This specific issue should be fixed ad of 5926526, and the fix will be included in the upcoming 0.11.16 release. @compcj Do you have some time to test that a node binary that includes this fix works on your setup?

[compcj]

OK, I'll try that this weekend. Thanks for your attention and effort!

[misterdjules]

I just realized that I missed a few things in the configuration of the build machine that builds linux binaries, and so v0.11.16 linux binaries still won't run n CentOS 6.5.

I'm very sorry for that, and this should be fixed for the next release. Thus, I'm adding this issue back to the next milestone (0.11.17).

In the meantime, building from source on CentOS 6.5 works with the default C/C++ toolchain.

[compcj]

I've compiled v0.11.15-release branch with commit 5926526 on my CentOS 6.5 machine(x86_64, with gcc 4.4.7).
It succeeded and passed all tests. The generated binary works immediately without install.
Looking forward to the fix in 0.11.17, thanks again for your time!

[misterdjules]

@compcj I built two linux binaries with the same job that build the release binaries. There's one for x86 and one for x64. If you could test them on your platform, that would be great!

[compcj]

Thanks for your binaries, it works on my machine, both binaries(x86 and x64) can pass all tests(except test-process-config) on my machine.
Environment:
CentOS 6.5 x86_64
glibc 2.12 x86_64/i686
libstdc++ 4.4.7 x86_64/i686

[misterdjules]

@compcj Thank you! Could you please paste the output of the failing test? I'd like to make sure it's unrelated to the changes made to the build environment.

[compcj]

@misterdjules seems it's related to different config, my config is the default one on the 0.11.16 release branch.
My config from v0.11.16-release branch:

{ target_defaults: 
   { cflags: [],
     default_configuration: 'Release',
     defines: [],
     include_dirs: [],
     libraries: [] },
  variables: 
   { clang: 0,
     gcc_version: 44,
     host_arch: 'x64',
     icu_small: false,
     node_install_npm: true,
     node_prefix: '',
     node_shared_cares: false,
     node_shared_http_parser: false,
     node_shared_libuv: false,
     node_shared_openssl: false,
     node_shared_v8: false,
     node_shared_zlib: false,
     node_tag: '',
     node_use_dtrace: false,
     node_use_etw: false,
     node_use_mdb: false,
     node_use_openssl: true,
     node_use_perfctr: false,
     openssl_no_asm: 0,
     python: '/usr/bin/python',
     target_arch: 'x64',
     uv_library: 'static_library',
     uv_parent_path: '/deps/uv/',
     uv_use_dtrace: false,
     v8_enable_gdbjit: 0,
     v8_enable_i18n_support: 0,
     v8_no_strict_aliasing: 1,
     v8_optimized_debug: 0,
     v8_random_seed: 0,
     v8_use_snapshot: true,
     want_separate_host_toolset: 0 } }

The process.config in x64 binray:

{ target_defaults: 
   { cflags: [],
     default_configuration: 'Release',
     defines: [],
     include_dirs: [],
     libraries: [] },
  variables: 
   { clang: 0,
     gcc_version: 44,
     host_arch: 'x64',
     icu_data_file: 'icudt54l.dat',
     icu_data_in: '../../deps/icu/source/data/in/icudt54l.dat',
     icu_endianness: 'l',
     icu_gyp_path: 'tools/icu/icu-generic.gyp',
     icu_locales: 'en,root',
     icu_path: './deps/icu',
     icu_small: true,
     icu_ver_major: '54',
     node_install_npm: true,
     node_prefix: '/',
     node_shared_cares: false,
     node_shared_http_parser: false,
     node_shared_libuv: false,
     node_shared_openssl: false,
     node_shared_v8: false,
     node_shared_zlib: false,
     node_tag: '',
     node_use_dtrace: false,
     node_use_etw: false,
     node_use_mdb: false,
     node_use_openssl: true,
     node_use_perfctr: false,
     openssl_no_asm: 0,
     python: '/data/opt/bin/python',
     target_arch: 'x64',
     uv_library: 'static_library',
     uv_parent_path: '/deps/uv/',
     uv_use_dtrace: false,
     v8_enable_gdbjit: 0,
     v8_enable_i18n_support: 1,
     v8_no_strict_aliasing: 1,
     v8_optimized_debug: 0,
     v8_random_seed: 0,
     v8_use_snapshot: false,
     want_separate_host_toolset: 0 } }

Diff:

    11c11,18
    <      icu_small: false,
    ---
    >      icu_data_file: 'icudt54l.dat',
    >      icu_data_in: '../../deps/icu/source/data/in/icudt54l.dat',
    >      icu_endianness: 'l',
    >      icu_gyp_path: 'tools/icu/icu-generic.gyp',
    >      icu_locales: 'en,root',
    >      icu_path: './deps/icu',
    >      icu_small: true,
    >      icu_ver_major: '54',
    13c20
    <      node_prefix: '',
    ---
    >      node_prefix: '/',
    27c34
    <      python: '/usr/bin/python',
    ---
    >      python: '/data/opt/bin/python',
    33c40
    <      v8_enable_i18n_support: 0,
    ---
    >      v8_enable_i18n_support: 1,
    37c44
    <      v8_use_snapshot: true,
    ---
    >      v8_use_snapshot: false,

[misterdjules]

@compcj Thanks again. These differences are expected, so it's all good. Closing as fixed for good this time, thank you for your help and support 👍