Skip to content

Unable to build 4.5.0 LTS on Darwin #8636

Description

@dmilith

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

Activity

  1. added
    buildIssues and PRs related to Node.js builds or CI infrastructure.
    macosIssues and PRs related to the macOS platform.
    on Sep 17, 2016
  2. dmilith commented on Sep 17, 2016

    @dmilith
    Author

    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
    
  3. MylesBorins commented on Sep 18, 2016

    @MylesBorins
    Contributor

    /cc @nodejs/lts @nodejs/build

  4. bnoordhuis commented on Sep 18, 2016

    @bnoordhuis
    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.

  5. dmilith commented on Sep 18, 2016

    @dmilith
    Author

    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+.

  6. dmilith commented on Sep 18, 2016

    @dmilith
    Author

    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).

  7. bnoordhuis commented on Sep 18, 2016

    @bnoordhuis
    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.

  8. imyller commented on Sep 18, 2016

    @imyller
    Member

    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.

  9. dmilith commented on Sep 18, 2016

    @dmilith
    Author

    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.

  10. dmilith commented on Sep 18, 2016

    @dmilith
    Author

    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.

  11. dmilith commented on Sep 18, 2016

    @dmilith
    Author

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

  12. imyller commented on Sep 18, 2016

    @imyller
    Member

    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.

  13. dmilith commented on Sep 18, 2016

    @dmilith
    Author

    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.

  14. bnoordhuis commented on Sep 19, 2016

    @bnoordhuis
    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    buildIssues and PRs related to Node.js builds or CI infrastructure.macosIssues and PRs related to the macOS platform.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions