When building custom `node` versions (e.g., floating features/fixes from different versions) it's often useful to specify a custom tag which easily identifies build when invoking `node -v`. Introduce a way to specify this tag in `node_version.h` file or by running `./configure --tag="<tag>"`. Insert it right after the patch version (and before `-pre`, if build is not a release).
Turns on -O3 and other optimizations that may produce buggy code with some toolchains. Use at your own risk.
This makes cross-compiling easier. i.e. from my mac: ./configure --dest-cpu=arm --dest-os=linux
Unconditionally compile V8 with -fno-strict-aliasing on all platforms. gcc 4.5.2 on sunos generates bad code when -fstrict-aliasing is enabled, which undoubtedly means that there are more buggy versions of gcc out there. -fstrict-aliasing does not give a significant performance boost so let's just disable it. Fixes #3736.
V8 on ARM requires that armv7 is set. We don't have a good way to detect the CPU model right now so we pick a default and hope that it works okay for the majority of people. Non-scientific sampling - the ARM hardware I have lying around the house - suggests that ARMv5 and ARMv6 are still most common so armv7=0 it is. This obviously needs to be revisited sometime in the future.
Compile at -O2 and disable optimizations that trigger gcc bugs. Some people still reported mksnapshot crashes after commit b40f813 ("build: fix spurious mksnapshot crashes for good" - so much for that). Average performance of the -O2 binary is on par with the -O3 binary. Variance on the http_simple bytes/8 benchmark appears to be slightly greater but small enough that the possibly of it being noise cannot be excluded. The new binary very slightly but consistently outperforms the -O3 binary (by about 0.5%) on the mostly CPU-bound bytes/102400 benchmark. That could be an artifact of the system I benchmarked it on, a Core 2 Duo with a puny 32 kB of L1 instruction cache. The smaller binary seems to play nicer with the cache.
A variety of gcc bugs made mksnapshot crash with either a segmentation fault or a 'pure virtual method callled' run-time error. After much wailing and gnashing of teeth I managed to deduce that the bugs show up when: 1. gcc 4.5.2 for i386-pc-solaris2.11 is used and -fstrict-aliasing is enabled, or 2. gcc version 4.4.6 for x86_64-redhat-linux is used and -ffunction-sections -finline-functions at -O2 or higher is enabled Therefore, disable -ffunction-sections and -fdata-sections unconditionally and disable -fstrict-aliasing only on Solaris. The -ffunction-sections and -fdata-sections switches were nonsense anyway because we don't link with -Wl,--gc-sections.
Make the variable naming consistent with the other strict aliasing var, v8_no_strict_aliasing.
It has been conclusively demonstrated that the -fstrict-aliasing bugs in gcc's optimizer are not limited to the 4.5.x releases only. Fixes #3601 among others.
Before this commit, we used to scan the output of `$CC -v` for strings like "gcc version x.y.z". It was pointed out that this approach fails with localized versions of gcc because those print (for example) "gcc versión x.y.z". Use the output of `$CC --version` instead and only look at the first line.
For consistency's sake, rename: --openssl-use-sys --openssl-includes --openssl-libpath To: --shared-openssl --shared-openssl-includes --shared-openssl-libpath And add --shared-openssl-libname while we're at it. The old switches still work but `./configure --help` won't print them. Fixes #3591.
Make configure start gyp with the same python interpreter that is used to run configure itself. Fixes an issue where configure fails with a SyntaxError because the user has multiple python binaries on his $PATH and the default one is too old.
For example: CC='ccache gcc' ./configure
This fixes the Windows build.
The gcc 4.5.x have various bugs that make V8 crash in various and interesting ways when -fstrict-aliasing is in effect.
This commit enables ETW events to be fired on Windows for existing DTrace probes. ETW instrumentation is enabled by default. It is possible to build node.exe without ETW instrumentation by using --without-etw option with configure script.
A build failure was introduced on c9676c9 in SmartOS systems. This makes it build properly.
Make the configure script warn the user about the lack of an acceptable C compiler on the system.
* fixes #2110 * includes V8 postmortem metadata in Solaris builds * adds GYP support for DTrace probes and ustack helper * ustack helper derives constants dynamically from libv8_base.a * build with DTrace support by default on SunOS
Before you had to enter a truthy value like: --openssl-use-sys=1
So that a 'config.gypi' file gets generated, which is required for the `process.config` object (see #2928).