5.x: Use .dylib extension for macOS dynamic libraries in Unix toolchain

[brentleyjones]

The autoconfigured Unix toolchain previously did not set any artifact_name_patterns, which meant that all artifacts used the default(Linux) patterns. This was incorrect in the case of dynamic libraries on macOS, which should have the extension .dylib rather than .so.

Fixes #11082.

Closes #14158.

PiperOrigin-RevId: 413363126
(cherry picked from commit 3f1672e)

[brentleyjones]

cc: @meteorcloudy

[brentleyjones]

Actually, let's wait for #14354 to be merged a well, and get both in at once.

[meteorcloudy]

Please ping me again when it's ready

[fmeum]

@meteorcloudy @brentleyjones Added #14369 with the second half of the fix.

[meteorcloudy]

https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/2273#ce43079f-ab1f-45aa-be89-18cd0f0ce098

exec ${PAGER:-/usr/bin/less} "$0" || exit 1
Executing tests from //cmake_with_data:test_with_shared_lib
-----------------------------------------------------------------------------
libc++abi: terminating with uncaught exception of type std::runtime_error: Could not open file: ./cmake_with_data/lib_b/liblib_b.so

Looks like this is already breaking rules_foreign_cc in downstream

[oquenchil]

How much of a breaking change is this and how beneficial is it? It might be a bit too late for 5.x.

[fmeum]

How much of a breaking change is this and how beneficial is it? It might be a bit too late for 5.x.

It changes the output name of shared library cc_binarys with the macOS auto-configured toolchain shipped with Bazel. The extension was arguably never correct (.so instead of .dylib, which e.g. leads to unexpected issues when loading JNI libraries), but of course it was convenient for tests that the name did not depend on macOS vs. Linux. This is also what seems to be breaking in rules_foreign_cc.

All in all, I agree that this may be too late for Bazel 5.

[meteorcloudy]

@fmeum Yeah, this change is definitely nice to have to fix the wrong name, but we probably want to give downstream more time to migrate and fix the incompatibilities. Thanks for your understanding!

[fmeum]

@fmeum Yeah, this change is definitely nice to have to fix the wrong name, but we probably want to give downstream more time to migrate and fix the incompatibilities. Thanks for your understanding!

Just for the record: Submitted bazel-contrib/rules_foreign_cc#834 to fix the issue before it becomes a failure.

[jsharpe]

Is there still a mechanism to compile a shared library with a .so extension on macOS?
Python extensions require a .so extension on macOS:

❯ find ~/Library/Python -iname '*.so'
/Users/james/Library/Python/3.9/lib/python/site-packages/psycopg2/_psycopg.cpython-39-darwin.so

[meteorcloudy]

cc_binary(
   name = "libfoo.so",
   srcs = [],
   ...

would still work, as long as the target name already ending with a dynamic library extension (.so, .dylib, .so, .pyd), it won't prepend or append extensions.