Turn off safe exception handlers, they're incompatible with how openssl is compiled / linked under MSVS 2012. Addresses the following build error: openssl.lib(x86cpuid.obj) : error LNK2026: module unsafe for SAFESEH image. [g:\jenkins\workspace\nodejs-oneoff\node.vcxproj] openssl.lib(x86.obj) : error LNK2026: module unsafe for SAFESEH image. [g:\jenkins\workspace\nodejs-oneoff\node.vcxproj] # etc. etc. g:\jenkins\workspace\nodejs-oneoff\Release\node.exe : fatal error LNK1281: Unable to generate SAFESEH image. [g:\jenkins\workspace\nodejs-oneoff\node.vcxproj] Fixes #4242.
This is the only thing preventing a manually compiled version of GCC (rather than Apple's provided llvm-gcc or heavily modified gcc 4.2) from working properly, so we might as well enable support for that. With this patch I was able to compile node using a manually compiled gcc 4.7.1. Closes #3887.
I disabled the -ffunction-sections and -fdata-sections switches in 202df30 because they're horribly buggy with some gcc/binutils combos. However, it turns out that the dtrace/ustack post-processing tool requires that V8 is compiled with said switches and was broken because of it. This commit turns them on again on SunOS systems. Let's hope for the best.
The system linker on SunOS doesn't understand --export-dynamic.
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.
* compile with -DOPENSSL_NO_SOCK and -DOPENSSL_NO_DGRAM, we don't need it * compile with -DOPENSSL_NO_GOST and -DOPENSSL_NO_HW_PADLOCK, works around the brain dead linker on solaris and maybe others * compile with -DTERMIOS, OS X doesn't have <termio.h> * compile with -D__EXTENSIONS__ on solaris, makes siginfo_t available * compile without -ansi on linux, it hides a number of POSIX declarations (sigaction, NI_MAXHOST, etc.)
* 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
A compiler bug in older versions of gcc makes it do unsafe optimizations at -O1 and higher. This manifested itself with (at least) gcc 4.5.2 on SmartOS because it made V8 hang in a busy loop. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45883