This repository was archived by the owner on Oct 7, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 7, 2020. It is now read-only.
[Converge] Build related commits #27
Description
There are a number of build related commits that need to reconciled. /cc @nodejs/build @misterdjules
59265264d56cfb7ced87f9b3666ec570152c5f47 src: make build pass with GCC < 4.5- nodejs/node-v0.x-archive@59265266168fe6720650052728f3e78a495b723f0b41ce3 build: add win32 convenience build rule- nodejs/node-v0.x-archive@6168fe6
Activity
jasnell commentedon May 22, 2015
See: nodejs/node#26 ... The Intl work also impacted the Build.
Fishrock123 commentedon May 22, 2015
iirc this isn't possible with the v8 we are using, cc @bnoordhuis
bnoordhuis commentedon May 22, 2015
Correct. 4.8 is the absolute minimum.
jasnell commentedon May 22, 2015
Another:
c0766eb1a4dac9d9b555be271ef84ad401ba91b0 build: fix use of strict aliasing- nodejs/node-v0.x-archive@c0766ebFishrock123 commentedon May 22, 2015
Also looks like it should just be dropped, again < 4.8 isn't going to work anyways.
jasnell commentedon May 22, 2015
@misterdjules @mhdawson ... do you know of anything that breaks without this?
Fishrock123 commentedon May 22, 2015
Well, older systems that use GCC < 4.8 will break trying to build without having GCC upgraded.
bnoordhuis commentedon May 22, 2015
And, FWIW, the library that was the source of the -Wstrict-aliasing warnings, src/queue.h, was removed in nodejs/node@7e779b4.
jbergstroem commentedon May 23, 2015
Clang could be a simpler install through package managers on those systems. Avoiding the gcc 4.8 is pretty much impossible if we want to use recent/stable v8's.
jasnell commentedon May 27, 2015
Ok, then I think this one is largely decided then. It would require a revert of the io.js changes in order to land. @misterdjules @cjihrig @trevnorris @orangemocha @mhdawson : if any of you think this is going to be a problem, we'll need to make the case to revert before we can proceed. Given that, I'm going to close this issue. We can reopen if new information is presented.
Fishrock123 commentedon May 27, 2015
@jasnell Hmmm, isn't the 2nd commit still valid? The windows 32 one?
jasnell commentedon May 27, 2015
Ah! missed that one. Perhaps, reopening until we can confirm
bnoordhuis commentedon May 27, 2015
nodejs/node-v0.x-archive@6168fe6 LGTM FWIW. It doesn't apply cleanly but you can get it to merge with a little nudge.
build: add win32 convenience build rule
misterdjules commentedon Jun 2, 2015
Added more info about nodejs/node-v0.x-archive@6168fe6 in nodejs/node#44 (comment).
Regarding nodejs/node-v0.x-archive@5926526 and nodejs/node-v0.x-archive@c0766eb, the goal for these changes was to be able to run node on Linux systems with older C++ runtimes (like CentOS 5.7 and early 6.x, I don't remember the specific version numbers).
The way io.js solved this was to use the RHEL developer toolset to build a node binary for Linux. This toolset basically makes node links against a C++ runtime that is old enough to run on Linux systems with older C++ runtimes, and adds newer C++ runtime features with a static library linked directly into the node binary. I think this approach is better and I created joyent/node-infra#4 to use it in joyent/node too. @mhdawson expressed some important concerns though here: joyent/node-infra#4 (comment).
In other words: as long as node runs on Linux systems in wide usage that ship an older C++ runtime, we don't need these two changes. We'll need input from @mhdawson to determine what needs to be done on IBM platforms.
mhdawson commentedon Jul 7, 2015
As stated earlier since the converged stream will have a newer level of V8 and V8 requires a newer compiler the converged stream will have a dependency on a later compiler so leaving out the first PR is not an issue.
I'll still concerned though that we don't have a full answer to the problem. Ignoring the issue of IBM based platforms, based on my understanding end users will only be able to build binaries for xlinux that run on older systems by one of the following:
So for example, if I'm an ubuntu shop running ubuntu 12 I'd either have to install a different platform or figure it out for myself how I could build binaries that would run on ubuntu 12.
rvagg commentedon Jul 8, 2015
Ubuntu 12.04 toolchain is fairly simple via a PPA: https://github.com/nodejs/build/blob/master/setup/ubuntu12.04/ansible-playbook.yaml#L25
Ubuntu 10.04 was just as simple: https://github.com/nodejs/build/blob/6b3867b99f555f3f1bb0b84c81ea20db2ca343b6/setup/ubuntu10.04/ansible-playbook.yaml#L25
Wheezy is a problem, although it's common enough that workarounds are appearing. For the ARMv7 machines I've managed to get gcc4.8 via default backport channels but I can't tell you if that goes for non-arm release lines too. Early on I created a procedure for compiling gcc4.8 on Wheezy, see https://github.com/nodejs/build/tree/master/setup/debian-wheezy-gcc for that.
It's actually easier to compile on non-RHEL/CentOS distros of the same age as it is on RHEL because of the hacky way you have to use SCLs.
Also, I read "TEST PURPOSE ONLY" in the same way as I read "DO NOT MACHINE WASH" on clothing labels, it's all about CYA.
mhdawson commentedon Jul 8, 2015
Having the info documented on how to get the toolchain you'll need for a given distro level would help. The other question is if we know whether binaries built with gcc48 on ubuntu 12.04 will run on ubuntu 10.04 ? The concern was not so much that you could not get the toolchain to build on a given distro level (but as you mention for Wheezy, its not always straight forward, so documentation would be helpful), but that resulting binaries might not run on earlier distro levels without having to update libstdc++ levels or some other components on the backlevel distro. That's the issue that dev toolset addresses.
rvagg commentedon Jul 8, 2015
So 12.04 binaries won't run on 10.04 but 10.04 is out of LTS so we've moved on anyway. The binaries we produce on CentOS5 will work on other CentOS 5 / RHEL5 / Wheezy-era distros without any additional extras. We build the ARM binaries on Wheezy-based distros for the same reason.
I think I've mentioned this before but it's worth saying again: any use of C++ features so far in V8 (and Node where it's crept in) are limited to those that don't require linking to libstdc++, so all that matters for the target distro is the version of libc. All that matters is where the binary is compiled and CentOS 5 and Wheezy represent the oldest reasonably supported distros out there.
To prove the point, here's a copy of what I've just run against a virgin CentOS 5 box:
rvagg commentedon Aug 24, 2015
I think this issue boiled down to the vcbuild.bat change but I believe that's redundant now thanks to the Intl support by @srl295: nodejs/node@1f12e032
I've filed a ticket to make sure Jenkins is doing the right thing by v4, currently I don't think it is: nodejs/node#2516