-
Notifications
You must be signed in to change notification settings - Fork 1
Use RHEL developer toolset to allow using recent compilers and linking with older libstdc++ #4
Comments
One issue is that the RHEL developer toolset only appears to be available on x. For p and z its not available so we'd like to avoid dependencies that require a later compiler if at all possible. |
I'll add that for future version with a later V8 we may not have a choice but for 0.12.X it would be good to avoid having to change compiler levels |
The other thing for 0.12.X is that for people in the community building their own binaries from the source it would limit were you could build. For example, you may have trouble building on an older SLES version. In the dev-policy discussions I think the general agreement was that we should avoid requiring new tooling levels (such as the compiler) except at major versions |
@mhdawson I agree with your concerns, let's be careful with these changes, and thank you very much for reminding us about that 👍 Just for my information, do the Power and Z platforms need to have binaries linked with older libstdc++ releases? |
Yes we see the same issues as we see on x unless you use the RHEL toolchain (complaints about missing symbols in libstdc++). During the time before the revert and 0.11.X needed a newer compiler we were looking at how to uses newer compilers. We already compiled on RHEL for x so we ended up using the RHEL dev toolchain to add the newer compiler levels for x but had to use an alternate approach for p/linux and z/linux. We wondered why we did not see the problem on x and that's when we figured out the additional support that came with the RHEL dev toolchain. We asked if there was an equivalent for the RHEL dev toolchain on those platforms but the answer was no. Since the revert it has been back on the burner but I do know we have to figure out how to handle this when Node incorporates a current v8 level. Some alternatives include static linking or bundling in the right libstdc++ libraries but those both have drawbacks. |
@mhdawson OK, sounds good. It seems we've been working on the same problems without knowing it :) I'm definitely interested in working in solving these problems. Should that take place in a/the LTS working group? |
Agreed that would be the logical place. We did most of the work before we were as actively involved in the TC otherwise I'm sure we would have been in sync :) |
Prior to releasing node v0.12.0, some changes were made to node's C++ layer and to libuv's build configuration so that it would not use features from relatively recent versions of the C++ runtime.
The goal was to allow node to run on older systems with older libstdc++ libraries. This required to float one patch on libuv, which makes the process of upgrading libuv less straightforward. There's another solution to that problem: using RHEL developer toolset. This is the solution that has been used in io.js for a while.
This toolset provides the more recent C++ runtime's features as a static library that is linked into binaries built using this toolset. As a result, one can run binaries generated by recent compilers on older systems.
The setup of the CentOS Jenkins agent (notably the environment variables that set the compiler to use) will need to be updated too.
The text was updated successfully, but these errors were encountered: