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!