Description of the problem / feature request:

Building a simple C++ application on osx that loads a third party (<something>.h + <libsomething>.dylib) DLL, I get dyld errors -> "image not found" at runtime when the DLL is loaded at runtime. I have looked at the binary with "otool -l" and found that cc_library .so files which Bazel builds from source get loaded with specific paths like this:

cmd LC_LOAD_DYLIB
      cmdsize 120
         name @loader_path/../../_solib_darwin_x86_64//<some_bazel_built_dll>.so (offset 24)

Bazel puts the third party .dylib one level deeper in <some_directory>, rather than with the rest of the .so files that bazel generates by compiling libraries. However, although the library .dylib file shows up in <some_directory>, bazel is annotating the binary with just an LC_RPATH and not an LC_LOAD_DYLIB command for this prebuilt DLL. This happens whether I use a cc_import or cc_library build rule for it. Specifically, the binary that uses the DLL library shows its last entry is my cc_import-ed DLL's directory:

          cmd LC_RPATH
      cmdsize 128
         path @loader_path/../../_solib_darwin_x86_64/<some_directory> (offset 12)

That path is valid: I have looked in bazel-bin and <some_directory>/<libsomething>.dylib exists. However, for whatever reason the runtime is not finding the <libsomething>.dylib file within that directory when it tries to actually load <libsomething>.dylib.

Feature requests: what underlying problem are you trying to solve with this feature?

Is there some difference in the linker/loader procedure for cc_import versus bazel-built DLL files? bazel has no problem generating LC_LOAD_DYLIB cmd for all the other DLLs, but seems to only generate a directory LC_RPATH cmd for the DLL that I am trying to link against / import from a third party.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I posted an example here: https://forums.opalkelly.com/t/dll-import-location-for-libokfrontpanel-dylib/1661/7

It is unclear if the problem is with bazel (especially given issue 1435 linked below), but since this is a third party DLL I don't know if it could be compounded by whatever method/flags the third party used to compile <libsomething>.dylib.

What operating system are you running Bazel on?

OSX

What's the output of bazel info release?

release 1.1.0

Have you found anything relevant by searching the web?

https://blog.krzyzanowskim.com/2018/12/05/rpath-what/
https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e41ae86172

This bazel bug seems to be similar or related:
bazel-contrib/rules_go#1435

Any other information, logs, or outputs that you want to share?

The DLL is a C++ library from Opal Kelly, and it works correctly when I just put it in /usr/local/lib. I just want cc_import and/or cc_library to correctly build a working application.