Node.js 6.x on macOS / Xcode 10.1 failing to compile (libc++)

[rvagg]

I don't get this, so hopefully someone else is tuned in to this better than I. I don't follow Xcode happenings and I think that's what this is all about. @srl295 or @ofrobots maybe?

If I compile the current 6.x head with Xcode 10.1 it fails on ICU:

warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library
      instead [-Wstdlibcxx-not-found]
In file included from ../deps/v8/src/libplatform/default-platform.cc:5:
../deps/v8/src/libplatform/default-platform.h:8:10: fatal error: 'functional' file not found
#include <functional>
         ^~~~~~~~~~~~
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library
      instead [-Wstdlibcxx-not-found]
In file included from ../deps/v8/src/libplatform/task-queue.cc:5:
../deps/v8/src/libplatform/task-queue.h:8:10: fatal error: 'queue' file not found
#include <queue>
         ^~~~~~~
1 warning and 1 error generated.

v6.x-staging has a few GYP related fixes for Xcode10, mainly because Apple LLVM went over 10 and string version matching became a problem. But those don't make any impact on this, it still fails in the same way.

7292a1e fixes this, it's on v8.x and later but not v6.x. It came in with V8 5.4. I don't know whether this one is semver-major for macOS, does it do anything to the binaries that might be a problem? We still use -mmacosx-version-min=10.7 so perhaps this is safe?

diff --git a/common.gypi b/common.gypi
index 0838af6b38..d1411ed1c6 100644
--- a/common.gypi
+++ b/common.gypi
@@ -385,6 +385,7 @@
             'xcode_settings': {
               'GCC_VERSION': 'com.apple.compilers.llvm.clang.1_0',
               'CLANG_CXX_LANGUAGE_STANDARD': 'gnu++0x',  # -std=gnu++0x
+              'CLANG_CXX_LIBRARY': 'libc++',
             },
           }],
         ],

What I don't understand is why this hasn't already been fixed or why I can't find an issue about it on the repo. The last change to ICU in 6.x was Dec 9, 2016 when we got ICU 58.2. Surely it didn't start requiring libc++ then? Is this simply an Xcode 10 thing and to support 10 we have to turn this on?

Right now I can't test the 6.x security fixes locally on my Mac because of this, but I don't really want to pull in that commit for a security release so I suppose this'll have to wait and I'll rely on CI to test Mac.

[Trott]

@rvagg What version of macOS are you running?

[Trott]

(FWIW, I get an error just running ./configure on my macOS machine with the v6.x branch HEAD.)

[Trott]

$ ./configure
WARNING: C++ compiler too old, need g++ 4.8 or clang++ 3.4.2 (CXX=c++)
creating icu_config.gypi
* Using ICU in deps/icu-small
Using version-specific floating patch tools/icu/patches/58/source/i18n/digitlst.cpp
creating icu_config.gypi
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': []},
  'variables': { 'asan': 0,
                 'coverage': 'false',
                 'debug_devtools': 'node',
                 'force_dynamic_crt': 0,
                 'host_arch': 'x64',
                 'icu_data_file': 'icudt58l.dat',
                 'icu_data_in': '../../deps/icu-small/source/data/in/icudt58l.dat',
                 'icu_endianness': 'l',
                 'icu_gyp_path': 'tools/icu/icu-generic.gyp',
                 'icu_locales': 'en,root',
                 'icu_path': 'deps/icu-small',
                 'icu_small': 'true',
                 'icu_ver_major': '58',
                 'llvm_version': 0,
                 'node_byteorder': 'little',
                 'node_enable_d8': 'false',
                 'node_enable_v8_vtunejit': 'false',
                 'node_install_npm': 'true',
                 'node_module_version': 48,
                 'node_no_browser_globals': 'false',
                 'node_prefix': '/usr/local',
                 'node_release_urlbase': '',
                 'node_shared': 'false',
                 'node_shared_cares': 'false',
                 'node_shared_http_parser': 'false',
                 'node_shared_libuv': 'false',
                 'node_shared_openssl': 'false',
                 'node_shared_zlib': 'false',
                 'node_tag': '',
                 'node_target_type': 'executable',
                 'node_use_bundled_v8': 'true',
                 'node_use_dtrace': 'true',
                 'node_use_etw': 'false',
                 'node_use_lttng': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'node_use_v8_platform': 'true',
                 'node_without_node_options': 'false',
                 'openssl_fips': '',
                 'openssl_no_asm': 0,
                 'shlib_suffix': '48.dylib',
                 'target_arch': 'x64',
                 'uv_parent_path': '/deps/uv/',
                 'uv_use_dtrace': 'true',
                 'v8_enable_gdbjit': 0,
                 'v8_enable_i18n_support': 1,
                 'v8_inspector': 'true',
                 'v8_no_strict_aliasing': 1,
                 'v8_optimized_debug': 0,
                 'v8_random_seed': 0,
                 'v8_trace_maps': 0,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0,
                 'xcode_version': 0}}
creating config.gypi
creating config.mk
WARNING: warnings were emitted in the configure phase
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance

xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance

Traceback (most recent call last):
  File "./configure", line 1483, in <module>
    run_gyp(gyp_args)
  File "tools/gyp_node.py", line 53, in run_gyp
    rc = gyp.main(args)
  File "tools/gyp/pylib/gyp/__init__.py", line 538, in main
    return gyp_main(args)
  File "tools/gyp/pylib/gyp/__init__.py", line 523, in gyp_main
    generator.GenerateOutput(flat_list, targets, data, params)
  File "tools/gyp/pylib/gyp/generator/make.py", line 2174, in GenerateOutput
    part_of_all=qualified_target in needed_targets)
  File "tools/gyp/pylib/gyp/generator/make.py", line 800, in Write
    self.Pchify))
  File "tools/gyp/pylib/gyp/generator/make.py", line 1195, in WriteSources
    cflags = self.xcode_settings.GetCflags(configname)
  File "tools/gyp/pylib/gyp/xcode_emulation.py", line 551, in GetCflags
    archs = self.GetActiveArchs(self.configname)
  File "tools/gyp/pylib/gyp/xcode_emulation.py", line 420, in GetActiveArchs
    xcode_archs_default = GetXcodeArchsDefault()
  File "tools/gyp/pylib/gyp/xcode_emulation.py", line 118, in GetXcodeArchsDefault
    xcode_version, _ = XcodeVersion()
  File "tools/gyp/pylib/gyp/xcode_emulation.py", line 1265, in XcodeVersion
    version = re.match(r'(\d\.\d\.?\d*)', version).groups()[0]
AttributeError: 'NoneType' object has no attribute 'groups'
$ 

The xcode-select errors were a known issue for a long time and were harmless, but the Python script blowing up is new to me.

macOS High Sierra (10.13.6) with xcode-select version 2349.

[rvagg]

10.14.1 xcode-select version 2354.

./configure isn't blowing up for me, even on v6.x. Does v6.x-staging change that error for you?

[richardlau]

See #23685 (comment).

TL;DR libstdc++ was deprecated in favour of libc++ on macOS and finally removed in Xcode 10. Of the current in support releases, Node.js 6.x is the only one built against libstdc++ (we specify libc++ from Node.js 8 onwards).

With my LTS hat on, I'd be extremely reluctant to change the C++ library being linked to for Node.js 6 based on nodejs/node-gyp#469 (comment).

[rvagg]

oof, that sucks. It'd be a shame to leave 6.x failing on modern Xcode. Perhaps we should slip some GYP hackery in there to detect Xcode version and switch when you're using a newer version.

[richardlau]

@Trott Maybe see if refack/GYP3#1 fixes it?

[richardlau]

@rvagg Perhaps for developer builds.

My worry would be mixing prebuilt addons linked against libstdc++ with Node.js linked against libc++ (or vice versa). It's less likely to be an issue for Node.js 8+ (since we specify libc++ in common.gypi which will be picked up by node-gyp).

[rvagg]

@richardlau yeah, prebuilt addons are a quite a problem if there really is binary incompatibility for compiles against the two libraries.

[refack]

Perhaps we should slip some GYP hackery in there to detect Xcode version and switch when you're using a newer version.

IMO this could be done in the .gyp files, we should have 'xcode_version': 10 available as a variable to test on around

diff --git a/common.gypi b/common.gypi
index 0838af6b38..d1411ed1c6 100644
--- a/common.gypi
+++ b/common.gypi
@@ -385,6 +385,7 @@
             'xcode_settings': {
               'GCC_VERSION': 'com.apple.compilers.llvm.clang.1_0',
               'CLANG_CXX_LANGUAGE_STANDARD': 'gnu++0x',  # -std=gnu++0x
+              'CLANG_CXX_LIBRARY': 'libc++',
             },
           }],
         ],

[ofrobots]

What version of XCode do we have in the CI? One thing to be careful about is whether the proposed fix to make 6.x buildable against XCode 10 could accidentally be used in the release CI due to machine config changes. I'd also be very wary of changing the C++ library, because of potential ABI incompatibilities for precompiled addons.

[refack]

Xcode8 can't be updated on the legacy release machine which runs macOS 10.10
Ref: nodejs/build#1358 (comment)

[bnoordhuis]

I'd also be very wary of changing the C++ library, because of potential ABI incompatibilities for precompiled addons.

Just to pile on: I agree, changing stdlibs midway through a release cycle is basically a no-go.

[rvagg]

yeah, so we're going to have to farewell 6.x in an un-compileable state for modern macos I suppose