Repository navigation
Node.js 6.x on macOS / Xcode 10.1 failing to compile (libc++) #24648
Description
Activity
- addedbuildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.
on Nov 25, 2018 @rvagg What version of macOS are you running?
(FWIW, I get an error just running
./configureon my macOS machine with the v6.x branch HEAD.)$ ./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-selecterrors 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.
- addedmacosIssues and PRs related to the macOS platform.Issues and PRs related to the macOS platform.
on Nov 25, 2018 10.14.1 xcode-select version 2354.
./configure isn't blowing up for me, even on
v6.x. Doesv6.x-stagingchange that error for you?See #23685 (comment).
TL;DR
libstdc++was deprecated in favour oflibc++on macOS and finally removed in Xcode 10. Of the current in support releases, Node.js 6.x is the only one built againstlibstdc++(we specifylibc++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).
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.
@Trott Maybe see if refack/GYP3#1 fixes it?
@rvagg Perhaps for developer builds.
My worry would be mixing prebuilt addons linked against
libstdc++with Node.js linked againstlibc++(or vice versa). It's less likely to be an issue for Node.js 8+ (since we specifylibc++incommon.gypiwhich will be picked up bynode-gyp).@richardlau yeah, prebuilt addons are a quite a problem if there really is binary incompatibility for compiles against the two libraries.
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
.gypfiles, we should have'xcode_version': 10available as a variable to test on arounddiff --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 version of XCode do we have in the CI? One thing to be careful about is whether the proposed fix to make
6.xbuildable 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.Reacted by Richard LauXcode8 can't be updated on the legacy release machine which runs macOS 10.10
Ref: nodejs/build#1358 (comment)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.
yeah, so we're going to have to farewell 6.x in an un-compileable state for modern macos I suppose
- added 2 commits that reference this issue
on Dec 30, 2018 - added a commit that references this issue
on Aug 10, 2021
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:
v6.x-staging has a few GYP related fixes for Xcode10, mainly because Apple LLVM went over
10and 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.7so perhaps this is safe?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.