Errors during BootstrapGNUMake after upgrading to macos v15 sdk
#1099
Comments
jungleraptor
added a commit
to swift-nav/rules_swiftnav
that referenced
this issue
Oct 6, 2023
The recent macos sdk v15 update has caused a number of issues with our builds that require various tweaks to our build settings to fix. ## Switch to ninja for cmake generator The `cmake` build process involves bootstrapping a gnu make binary from source. The update has caused some strange build errors during this process. More info can be found in the ticket I've created here: bazel-contrib/rules_foreign_cc#1099 In the meantime we can just switch to using the ninja generator. ## Drop support for shared linking We make liberal use of "weak linking" for various purposes across the codebase - usually implemented using function pointers for (I assume) portability. However, this means that most of our libraries can't really be built as shared libraries due to resulting "undefined reference" errors. In bazel the build system will by default always try to build the shared library unless `linkstatic` is set to `True`. So on mac this was causing errors during the normal build. Not sure why linux was not having problems (all our CMake builds fail when `-DBUILD_SHARED_LIBS=TRUE`). To fix this I added `-undefined dynamic_lookup` to the link flags on mac to tell the linker we'll supply the symbols later at the final link step. Now with the update, for whatever reason these flags appear to be causing the following crash on m1 macs when the linker tries to link a binary: ``` Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging 0 0x102277648 __assert_rtn + 72 1 0x10224c6c8 ld::AtomFileConsolidator::addAtomFile(ld::AtomFile const*, ld::AtomFile const*, bool) + 4860 2 0x1022581d0 ld::AtomFileConsolidator::addAtomFile(ld::AtomFile const*) + 148 3 0x102275b20 ld::pass::stubs(ld::Options const&, ld::AtomFileConsolidator&) + 1644 4 0x10225f84c ld::AtomFileConsolidator::resolve() + 12232 5 0x1021ea1a8 main + 9104 ld: Assertion failed: (slot < _sideTableBuffer.size()), function addAtom, file AtomFileConsolidator.cpp, line 2158. clang: error: linker command failed with exit code 1 (use -v to see invocation) INFO: Elapsed time: 190.377s, Critical Path: 36.73s INFO: 1484 processes: 210 internal, 1274 darwin-sandbox. FAILED: Build did NOT complete successfully ``` Since we've never really supported shared linking except in some exceptional cases, I've disabled shared library builds by default across all our code and thus can remove the problematic flags (and probably get a perf boost as well). ## Make the minimum macos target consistent Another annoyance with the mac builds was that the bazel code was getting compiled with a different macos deployment target than the cmake libraries, which resulting in the build output getting spammed with linker warnings referencing this difference. On my system the bazel target was `13.0`, while the cmake value was `13.6`. I'm not sure how (as of our current version of bazel 6.2) this value is computed. In CMake it's interpolated from the system. To fix this I've wired up our toolchain to respect the [macos_minimum_os](https://bazel.build/reference/command-line-reference#flag--macos_minimum_os) flags and add `-mmacos-version-min` to our build. This is just taken from the most recent `HEAD` of `bazel` which is not in 6.x. The CMake side requires explicitly setting [CMAKE_OSX_DEPLOYMENT_TARGET](https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_DEPLOYMENT_TARGET.html) variable to the same value. It would be better if `rules_foreign_cc` also respected the `macos_minimum_os` flag so the value would not have to be hardcoded. We can perhaps open a ticket to request this. `13.0` seems like a reasonable minimum deployment target since these builds are only intended for development machines. ## Testing I've tested these changes on m1 and intel macs as well as the following test PR's: - https://github.com/swift-nav/starling/pull/8677 - https://github.com/swift-nav/orion-engine/pull/7239
|
We're observing this too. From what I could tell, the final This patch seems to fix it: From f84270c6bd0b513dbd77431688ab387ddd0f4916 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ricard=20Sol=C3=A9?= <[email protected]>
Date: Thu, 12 Oct 2023 18:03:11 +0200
Subject: [PATCH] gnumake: unsets -undefined dynamic_build if found
---
foreign_cc/built_tools/make_build.bzl | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/foreign_cc/built_tools/make_build.bzl b/foreign_cc/built_tools/make_build.bzl
index 0baaa5c..f807d27 100644
--- a/foreign_cc/built_tools/make_build.bzl
+++ b/foreign_cc/built_tools/make_build.bzl
@@ -71,8 +71,10 @@ def _make_tool_impl(ctx):
if absolute_ar == "libtool" or absolute_ar.endswith("/libtool"):
arflags.append("-o")
+ _joined_non_sysroot_ldflags = _join_flags_list(ctx.workspace_name, non_sysroot_ldflags)
if os_name(ctx) == "macos":
- non_sysroot_ldflags += ["-undefined", "error"]
+ _joined_non_sysroot_ldflags = _joined_non_sysroot_ldflags.replace("-undefined dynamic_lookup", "")
+ _joined_non_sysroot_ldflags += " -undefined error"
env.update({
"AR": absolute_ar,
@@ -80,7 +82,7 @@ def _make_tool_impl(ctx):
"CC": absolute_cc,
"CFLAGS": _join_flags_list(ctx.workspace_name, non_sysroot_cflags),
"LD": absolute_ld,
- "LDFLAGS": _join_flags_list(ctx.workspace_name, non_sysroot_ldflags),
+ "LDFLAGS": _joined_non_sysroot_ldflags,
})
configure_env = " ".join(["%s=\"%s\"" % (key, value) for key, value in env.items()])
--
2.38.1
|
ohadravid
added a commit
to ohadravid/rules_foreign_cc
that referenced
this issue
Oct 19, 2023
goniz
pushed a commit
to goniz/rules_foreign_cc
that referenced
this issue
Oct 22, 2023
|
Believe I am seeing this as well, MacOS 13.5 |
|
Same issue on MacOS 14 I am using the latest version: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We've observed at least two separate issues during the
BootstrapGNUMakestep on users who've upgraded their machines to the latestv15release of the mac command line tools or the new xcode sdk.Macos version: Venture 13.6
Bazel version: 6.2.0
rules_foreign_cc: d4b19bb010ca5d433850c1d9db0510c2fd395aae758ae37f02930944596220ec
Error 1:
Error 2:
The text was updated successfully, but these errors were encountered: