fix: various mac build fixes and improvements [DIP-311]

[jungleraptor]

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

[silverjam]

Pending anymore testing you'd like to do

[jungleraptor]

Test PR's are passing so I'm going to merge