Enable supports_dynamic_linker feature on darwin

[fffonion]

The supports_dynamic_linker is not turned on, resulting shared library is not producde by cc_library or cc_test

Ref: bazelbuild/bazel#16479 https://github.com/bazelbuild/bazel/blob/c5cb07ac4603cef03d7037d603971e1f4e9184c9/src/main/starlark/builtins_bzl/common/cc/cc_library.bzl#L94

[fffonion]

The linked ref also mentioned it was removed due to bazelbuild/bazel@ec55533. But I'm not sure if it's safe to enable just on darwin.

[keith]

It's not safe to. For the same reason from that commit message. There are some other threads about this around too I can probably dig up later

[fffonion]

Thanks for the reply @keith . In that case is cc_shared_library the preferred way to get a .dylib on macOS? I'm bit hesitated
to use it as it's marked as experimental.

[keith]

Yes. You can also use cc_binary with the linkshared attribute. The difference being both of those require you to fully specify your deps to move issues to link time instead of runtime

[fffonion]

Thank you!

[keith]

related links:

• Remove use of -undefined dynamic_lookup on darwin bazel#16414
• Remove supports_dynamic_linker_feature from macOS unix crosstool bazel#17624
• grpc Mac bazel build fails because of thread-local, but make passes bazel#4341

the general issue is that when you were creating this type of library you would link your static library as a dylib without any of your dependencies, and any symbols that weren't there were just assumed to exist at runtime. This is very much against the model that apple platforms try to enforce of having all symbols understood at link time. I believe the reason this is ok on linux is that --no-allow-shlib-undefined is passed to final binary links, which makes sure any of this type of issue is caught. AFAIK there isn't a macOS equivalent so the end result is just missing symbols at runtime. Really this just wasn't a sensible default to have, since it very easily allows you to create an invalid binary just because you under-defined your deps. cc_shared_library is definitely the ideal solution to this, since all your dependencies have to be understood at link time instead. If you want to create one of these unsafe libraries it's still possible if you write your own rule and just call the underlying cc_common APIs directly. Or like I said doing cc_binary(linkshared=True and optionally passing -undefined dynamic_lookup to the linker can also get you the same behavior.

[fffonion]

I see, thanks for you detailed reply. I now understands the limitation on macOS. I do have a generic question regarding those cc_* rules after reading your reply though. If I want to produce a shared library for binary redistribution, for example I want to submit libmyproject to homebrew. Is it true that I would better use cc_binary or cc_shared_library instead of cc_library, as the later is intended for intermediate usage? The reason I'm asking this is because it seems cc_binary doesn't export any functions in the produced shared library by default, but cc_shared_library does. So I was wondering if I was going the wrong path, as I see the .so file produced by cc_library on linux does export functions so it can used for both linking and distribution.

[keith]

i think you'd be better off with cc_shared_library, i wouldn't be worried about the experimental-ness anymore (with bazel 7 it's no longer named experimental). I think you could make it work with cc_binary though with -exported_symbols_list on macOS

[fffonion]

Thank you again! I will have a try of that flag!