Commits on Oct 24, 2022

1. Use otool to read dylib install name …

   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>

   

   keith and jlaxson committed Oct 24, 2022
   Configuration menu

   • View commit details
   • Copy full SHA for 539665a
   • Browse repository at this point

   Copy the full SHA

   539665a View commit details

   Browse the repository at this point in the history