Repository navigation
Cannot build 4.3.2 on OS X 10.8.5 #5550
Description
Activity
Not seeing the errors on a second system running OS X 10.10.1.
- addedbuildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.macosIssues and PRs related to the macOS platform.Issues and PRs related to the macOS platform.opensslIssues and PRs related to the OpenSSL dependency.Issues and PRs related to the OpenSSL dependency.
on Mar 3, 2016 Out of curiosity, what does
gcc -vshow?On our 10.8.5 system (fails):
$ gcc -v Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) $on 10.10.1 (passes):
$ gcc -v Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix $@richardlau Also pointed out this may be an upstream issue, see https://www.mail-archive.com/openssl-dev%40openssl.org/msg43040.html
If that's real gcc, I believe you need to use gcc 4.8.x or newer (in general).
Works for me on 10.8.5 with this:
$ c++ -v Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.6.0 Thread model: posixFor comparison (our 10.8.5):
$ c++ -v Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.5.0 Thread model: posix@bnoordhuis what is
gcc -voutputting out your system?From the openssl thread it looks like there is an alternative patch that someone tested that is building, so we at least have confirmation that this is happening in the wild
$ gcc -v Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~148/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~148/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)Applying the patch suggested on the OpenSSL mailing list appears to resolve the issue https://github.com/openssl/openssl/pull/597/files.
Here are some examples of assembler (asm_obsolete) generated before and after the patch.
Before:
.p2align 4 L$key_expansion_128: movups %xmm0,(%rax) leaq 16(%rax),%rax L$key_expansion_128_cold: shufps $0b00010000,%xmm0,%xmm4 xorps %xmm4,%xmm0 shufps $0b10001100,%xmm0,%xmm4 xorps %xmm4,%xmm0 shufps $0b11111111,%xmm1,%xmm1 xorps %xmm1,%xmm0 .byte 0xf3,0xc3After:
.p2align 4 L$key_expansion_128: movups %xmm0,(%rax) leaq 16(%rax),%rax L$key_expansion_128_cold: shufps $16,%xmm0,%xmm4 xorps %xmm4,%xmm0 shufps $140,%xmm0,%xmm4 xorps %xmm4,%xmm0 shufps $255,%xmm1,%xmm1 xorps %xmm1,%xmm0 .byte 0xf3,0xc3Regenerating the asm folder shows similar issues but in fewer places, but I really don't understand why @bnoordhuis is not seeing this issue, the build system decides to use asm or asm_obsolete based on: https://github.com/nodejs/node/blob/master/deps/openssl/openssl.gypi#L1043 so he should also be falling back to asm_obsolete folder. @bnoordhuis does your machine compile the assembler from the asm or asm_obsolete folders?
In fact, the checks done in https://github.com/nodejs/node/blob/master/configure#L442:L463 appear to fail completely on the latest OS X because the banner of clang has changed:
Stefan@Stefans-MacBook-Pro:~$ sw_vers -productVersion 10.11.3 Stefan@Stefans-MacBook-Pro:~$ cc -v Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin15.3.0 Thread model: posixTherefore my machine fails to use the higher performance code path despite having support for AVX2.
@stefanmb would you be willing to send a PR to fix the
./configureto work on the latest OSX?@thealphanerd Sure, as soon as I figure out how to interpret the newer version numbers. :)
Based on https://en.wikipedia.org/wiki/Xcode#Version_comparison_table everything after clang-500.2.75 should be okay.
does your machine compile the assembler from the asm or asm_obsolete folders?
asm_obsolete. I noticed it uses
ccand notgcclike it seems to do on @richardlau's machine. For me,cc -vprints:$ cc -v Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.6.0 Thread model: posix@bnoordhuis I have access to @richardlau's machine and that's what I used to test the fix. Now, looking at that assembler, it's obvious those immediates have the same values but in different bases, I wonder if certain versions of the toolchain can understand binary as well as base10.
@thealphanerd As requested, I've fixed the clang detection for OS X: #5553
@bnoordhuis Running the offending line with cc (or c++) works, gcc does not!
@richardlau @bnoordhuis So I can confirm by removing "export CC=gcc" from the build scripts (ours, not Node's) everything is resolved. This problem may break others, but I'm not sure if there is anything else to do at this point other than keep a record of the problem. Thanks for the help!
Thanks @stefanmb
Getting compilation errors on OS X 10.8.5 with v4.3.2 (previous versions, e.g. v4.3.1, built successfully on the same system) that must be related to the OpenSSL update (since that's the only thing that changed):
gist of complete build log