Link libc++/libc++abi on macOS for static LLVM builds

[751K]

Problem

Building openvaf-r on macOS against an official prebuilt LLVM (e.g. the LLVM-*-macOS-ARM64.tar.xz release tarballs) fails at the final link with:

ld: symbol(s) not found for architecture arm64
  "operator new(unsigned long, std::nothrow_t const&)"
  "___cxa_guard_acquire" / "___cxa_guard_release" / "___cxa_pure_virtual"
  ...

Root cause

Those tarballs ship only static component libraries — there is no libLLVM.dylib. mir_llvm requests llvm-sys with the prefer-dynamic feature, so with no dylib present it falls back to linking the static archives. Those archives are C++ and need libc++/libc++abi for their runtime symbols, which the final link doesn't pull in.

Homebrew's LLVM ships libLLVM.dylib, so the macOS CI path never hits this.

Fix

Link c++ and c++abi in the existing #[cfg(target_os = "macos")] block of openvaf-driver/build.rs. This only affects the final binary link (no full rebuild), and is harmless when a dynamic libLLVM is used since those libs come in transitively anyway.

Alternatives considered

Happy to switch to whichever you prefer:

• gate the extra libs on llvm-config --shared-mode == static, or
• document "use Homebrew LLVM on macOS" instead of changing the build.

Testing

LLVM 21.1.6 official arm64 release (LLVM-21.1.6-macOS-ARM64.tar.xz), Apple Silicon. With this change openvaf-r builds cleanly and compiles integration_tests/CCCS/cccs.va to a valid arm64 .osdi exporting the expected OSDI_* symbols.

[gemini-code-assist]

Code Review

This pull request updates the macOS build script (build.rs) to link against C++ runtime libraries, enabling compatibility when building against static LLVM release tarballs. The reviewer pointed out that explicitly linking c++abi is redundant on macOS since libc++ transitively links to it, and suggested removing that line.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

On macOS, libc++ (linked via c++) transitively links to libc++abi [16.1.1]. Therefore, explicitly linking c++abi is redundant and unnecessary, as the dynamic linker (dyld) will automatically load it and resolve all C++ runtime symbols (such as __cxa_guard_acquire and __cxa_pure_virtual). We can safely remove the explicit link to c++abi.

Suggested change

	println!("cargo:rustc-link-lib=dylib=c++");
	println!("cargo:rustc-link-lib=dylib=c++abi");
	println!("cargo:rustc-link-lib=dylib=c++");