Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to build 4.5.0 LTS on Darwin #8636

Closed
dmilith opened this issue Sep 17, 2016 · 13 comments
Closed

Unable to build 4.5.0 LTS on Darwin #8636

dmilith opened this issue Sep 17, 2016 · 13 comments
Labels
build Issues and PRs related to build files or the CI. macos Issues and PRs related to the macOS platform / OSX.

Comments

@dmilith
Copy link

dmilith commented Sep 17, 2016

OSX 10.11, Darwin 15.6.0 - x86_64:
Building Node exactly same way as I did build 6.6.0 before:
http://ół.pl/3227d2ab6afa3d0db94973a7e02d33b4.png

@targos targos added build Issues and PRs related to build files or the CI. macos Issues and PRs related to the macOS platform / OSX. labels Sep 17, 2016
@dmilith
Copy link
Author

dmilith commented Sep 17, 2016

This might be also related to update to Xcode 8 with Clang 8:

Apple LLVM version 8.0.0 (clang-800.0.38)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

@MylesBorins
Copy link
Contributor

/cc @nodejs/lts @nodejs/build

@bnoordhuis
Copy link
Member

I believe Xcode 8 defaults to libc++ rather than libstdc++. We no longer use anything from TR1 in master but for v4, we probably need to set 'CLANG_CXX_LIBRARY': 'libstdc++' explicitly. Does this patch help?

diff --git a/common.gypi b/common.gypi
index 811a7b3..8007b41 100644
--- a/common.gypi
+++ b/common.gypi
@@ -300,6 +300,7 @@
         'defines': ['_DARWIN_USE_64_BIT_INODE=1'],
         'xcode_settings': {
           'ALWAYS_SEARCH_USER_PATHS': 'NO',
+          'CLANG_CXX_LIBRARY': 'libstdc++',
           'GCC_CW_ASM_SYNTAX': 'NO',                # No -fasm-blocks
           'GCC_DYNAMIC_NO_PIC': 'NO',               # No -mdynamic-no-pic
                                                     # (Equivalent to -fPIC)

Switching to libc++ is not an option (in v4) because that would break ABI.

@dmilith
Copy link
Author

dmilith commented Sep 18, 2016

Since which version Node requires GCC/GNU-based base system? I need to revert to latest that worked perfectly with libc++. AFAIR there's no libstdc++ in both Darwin 10.11+, and FreeBSD 10+, 11+.

@ChALkeR ChALkeR added the v4.x label Sep 18, 2016
@dmilith
Copy link
Author

dmilith commented Sep 18, 2016

I tried applying that patch on 6.6 - frankly that caused this bug from 4.4.. http://ół.pl/e6877a7241e538c5a892eb8995f24220.png

without patch 6.6 builds fine (when using LLVM Linker instead Apple built in one).

@bnoordhuis
Copy link
Member

Your original report is about v4.5.0? Did you try the patch with that version?

Also, can you upload images to GH? That external site you are linking to is timing out for me. Better yet, if it's plain text, just paste it into a gist if it's long or in a comment if it's short.

@imyller
Copy link
Member

imyller commented Sep 18, 2016

To be thorough, I set up a virtual machine with OSX 10.11.6 (all available updates applied), installed Xcode 8 (default settings, xcodebuild -license applied), downloaded fresh Node.js v4.5.0 LTS source tarball and compiled:

./configure
make -j8

The result was few minor warnings during V8 compilation (nothing critical) and warning from clang:

clang: warning: libstdc++ is deprecated; move to libc++ with 
a minimum deployment target of OS X 10.9

No errors. node binary compiled successfully and passed make -j8 test test suite with perfect score.

I'm unable to reproduce the 4.5.0 LTS compilation issue and not quite sure what exactly needs to be modified in vanilla environment to make it fail compiling.

@dmilith
Copy link
Author

dmilith commented Sep 18, 2016

I linked explicitly with libc++ under Darwin by default. That's interesting issue anyway - cause LLVM claims to have ABI compatibility of libc++ and libstdc++..
Doing rebuild to confirm that.

@dmilith
Copy link
Author

dmilith commented Sep 18, 2016

Heh, after linking with libstdc++ ... issue remained the same:

⇢ ldd `which node`
/Software/Node/exports/node:
    /usr/lib/libdtrace.dylib (compatibility version 1.0.0, current version 130.0.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
    /Software/Node/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
    /Software/Node/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /Software/Node/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1258.1.0)

but: http://ół.pl/5a9167ffc6dc337ba8d80244f3b73e8c.png
:) Issue is getting interesting.

@dmilith
Copy link
Author

dmilith commented Sep 18, 2016

Are you sure You're testing that on box with both ipv4 and ipv6 routable addresses?

@imyller
Copy link
Member

imyller commented Sep 18, 2016

Care to explain how the ipv4 and ipv6 routable addresses are relevant for Unable to build 4.5.0 LTS on Darwin issue you've reported?

I'm able to build, test and run Node.js 4.5.0 LTS from source tarball on vanilla OSX 10.11.6 and Xcode 8. The virtual machine I tested in has only IPv4 connectivity but I really don't think that affects the <tr1/type_traits> header file not found error.

I'd suggest you take a clean environment (both OS and network infrastructure) and verify the results there and then iterate towards to your current build environment to find out what differs.

@dmilith
Copy link
Author

dmilith commented Sep 18, 2016

Build issue with libc++ vs libstdc++ is common issue - affects both 4.x and 6.x. You closed unresolved issue so I'm showing you here that it turns out to be the same issue.

I will fix it myself. I don't have time for your politics.

@dmilith dmilith closed this as completed Sep 18, 2016
@bnoordhuis
Copy link
Member

cause LLVM claims to have ABI compatibility of libc++ and libstdc++..

LLVM claims no such thing. Some of the low-level plumbing like RTTI and exception handling is ABI-compatible, high-level stuff such as the STL is not. You may be confusing libc++ with libc++abi - similar names, different things.

I will fix it myself. I don't have time for your politics.

If you are going to keep up the antagonistic attitude, then yes, it's better that you go away and don't come back. You are welcome here but not when you act like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI. macos Issues and PRs related to the macOS platform / OSX.
Projects
None yet
Development

No branches or pull requests

6 participants