Use otool to read dylib install name

[keith]

When linking an executable on darwin, cc_wrapper.sh contains functionality to ensure rpath entries and shared library install names are relative and match the intended paths that will be used in downstream actions. This depends on being able to traverse symlinks from the _solibs path (like
_solib_darwin_x86_64/_U_S_S_Cgenlib_Uimport___U/libgenlib.so) to the actual file (like bazel-out/darwin-opt-exec-31C2CD59/bin/libgenlib.so). This also assumes that the library has its internal install name equal to that latter path - this seems to be generally true right now, but is maybe a bit brittle.

This system breaks down when doing linking on a remote executor, because Bazel does not encode symlinks, and so the file shows up in _solib_darwin_x86_64 as a real file, and the wrapper picks the wrong install name. The resulting executable works when run directly from bazel-bin/bazel-out on a local machine, but will not work via bazel run, or when used in remote actions.

This change uses otool to read the install name of the target library, which is guaranteed to match what was embedded into the executable during link time. This result will be immune to the peculiarities of how symlinks are used and what install_name is encoded into the shared library during its creation.

Co-authored-by: John Laxson jlaxson@mac.com

[Yannic]

There's also --incompatible_macos_set_install_name, which (IIRC) makes the whole wrapper not needed anymore.

[keith]

I completely forgot about that, do you think we should try to flip it? Been around for a while

[keith]

Looks like it might have rotted a bit:

% otool -L bazel-bin/libfoo.so
bazel-bin/libfoo.so:
        @rpath/liblibfoo.so (compatibility version 0.0.0, current version 0.0.0)

note the duplicate lib prefix, my target here is just named foo

[Yannic]

IIRC, it broke rules_go last time I checked downstream. Let's see if we can flip it

[pcjanzen]

There were some problems in rules_rust specifically due to the fact that the install name of a cc_binary(linkshared=True) is mangled with --incompatible_set_macos_install_name (even though it shouldn't be): #15261

[keith]

we should probably merge this in the meantime regardless, because even if we flip it now it will take a while before we can entirely remove this codepath

[keith]

looks like some real failures #16620, I'm not going to debug them atm

[keith]

I've setup a bounty for flipping that here: bazel-contrib/SIG-rules-authors#68

[keith]

not sure why this one works and that one doesn't, but probably flipping that flag is the ideal solution