Apple's system linker, ld, does not support this option, though I believe the option -exported_symbol may be equivalent.
Since Apple ld is OS-specific, it might be OK to just use a typical select statement here. Like this:
diff --git a/common/BUILD b/common/BUILD
index 8933cf5e..aad7cad9 100644
--- a/common/BUILD
+++ b/common/BUILD
@@ -553,7 +553,10 @@ cc_library(
# use the dynamic linker to find the symbols at runtime. This only works if they are exported as
# dynamic symbols. When static linking, our symbols are not exported as dynamic by default. We
# workaround this by explicitly passing our symbols to the linker for exporting.
- linkopts = ["-Wl,--export-dynamic-symbol=%s" % dynamic_symbol for dynamic_symbol in _DYNAMIC_SYMBOLS],
+ linkopts = select({
+ "@bazel_tools//src/conditions:darwin": ["-Wl,-exported_symbol -Wl,%s" % dynamic_symbol for dynamic_symbol in _DYNAMIC_SYMBOLS],
+ "//conditions:default": ["-Wl,--export-dynamic-symbol=%s" % dynamic_symbol for dynamic_symbol in _DYNAMIC_SYMBOLS],
+ }),
deps = [
":casting",
":json",
Testing locally, this does seem to make the build go further.
P.S.: It seems like all of LLVM, GNU Binutils and Apple's linker have equivalent options where you can specify a file that contains a list of symbols to export; -exported_symbols_list on Apple LD and --export-dynamic-symbol-list on GNU Binutils and LLVM's linker. That said, the format is different between the two: the LLVM and GNU Binutils version seems to match the symbol versions file and look like { a; b; } whereas the Apple linker version appears to be one per-line, like:
a
b
Maybe still worth it to make the linker args more reasonable. (Eventually it's bound to breach the argv limit on some platform, I'm sure.)
P.P.S: The equivalent windows_msvc option might be a little trickier to nail down. Realistically the closest Win32 analogue I can think of is linker export definitions, which is yet another format that looks something like:
LIBRARY lib
EXPORTS
a
b
It's a little awkward that every platform has these little quirks with linking that can't be hidden away by Bazel somehow.
Since 16ca259aeea2330998f3665c289267a82a738d46, cel-cpp fails to build correctly on AArch64 Darwin, due to using
-Wl,--export-dynamic-symbol
:Apple's system linker,
ld
, does not support this option, though I believe the option-exported_symbol
may be equivalent.Since Apple ld is OS-specific, it might be OK to just use a typical
select
statement here. Like this:Testing locally, this does seem to make the build go further.
P.S.: It seems like all of LLVM, GNU Binutils and Apple's linker have equivalent options where you can specify a file that contains a list of symbols to export;
-exported_symbols_list
on Apple LD and--export-dynamic-symbol-list
on GNU Binutils and LLVM's linker. That said, the format is different between the two: the LLVM and GNU Binutils version seems to match the symbol versions file and look like{ a; b; }
whereas the Apple linker version appears to be one per-line, like:Maybe still worth it to make the linker args more reasonable. (Eventually it's bound to breach the argv limit on some platform, I'm sure.)
P.P.S: The equivalent
windows_msvc
option might be a little trickier to nail down. Realistically the closest Win32 analogue I can think of is linker export definitions, which is yet another format that looks something like:It's a little awkward that every platform has these little quirks with linking that can't be hidden away by Bazel somehow.