OS X: Nonexistant shared library search path when linking in a Bazel-generated shared object

[allenlavoie]

Description of the problem / feature request / question:

(Largely irrelevant background) I'm attempting to split out a shared object from TensorFlow that extensions (custom user ops) can rely on. This means TensorFlow itself will need to rely on the same shared object (so it can access the list of ops registered by custom op libraries), which looks like it will involve cc_binary rule with linkshared=1 which gets re-used within TensorFlow (e.g. our Python extension _pywrap_tensorflow.so will depend on this cc_binary rule).

I have a prototype which is working, although I've run into an OS X linking issue which means tests on that platform need to be built with linkstatic=1.

If possible, provide a minimal example to reproduce the problem:

At https://github.com/allenlavoie/bazelrepro

git clone https://github.com/allenlavoie/bazelrepro.git
cd bazelrepro/
bazel run :link_repro

The important bit (the source files are ~trivial):

cc_library(
	name="regular_dep",
	hdrs=["regular_dep.h"],
	srcs=["regular_dep.cc"],
)

cc_binary(
	name="libsome.so",
	linkshared=1,
)

cc_test(
	name="link_repro",
	srcs=[
            "test.cc",
            ":libsome.so" # Removing this fixes the test!
          ],
	deps=[":regular_dep"],
)

This gets me output like:

INFO: Reading 'startup' options from /etc/bazel.bazelrc: --batch
INFO: Found 1 target...
Target //:link_repro up-to-date:
  bazel-bin/link_repro
INFO: Elapsed time: 6.749s, Critical Path: 0.21s

INFO: Running command line: bazel-bin/link_repro
dyld: Library not loaded: @loader_path/_solib_darwin_x86_64/_U_S_S_Clink_Urepro___U/liblibregular_Udep.so
  Referenced from: /private/var/tmp/_bazel_allen/5fdaac27a275125cca7a7ab6df9508e8/execroot/__main__/bazel-out/darwin_x86_64-fastbuild/bin/link_repro
  Reason: image not found

Running otool -L on the binary:

otool -L bazel-bin/link_repro
bazel-bin/link_repro:
	@loader_path/_solib_darwin_x86_64/_U_S_S_Clink_Urepro___U/libsome.so (compatibility version 0.0.0, current version 0.0.0)
	@loader_path/_solib_darwin_x86_64/_U_S_S_Clink_Urepro___U/liblibregular_Udep.so (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2)

bazel-bin/_solib_darwin_x86_64/liblibregular_Udep.so does exist, but the path above does not. Removing ":libsome.so" from the srcs of the link_repro means the test passes, and otool -L on the binary returns:

otool -L bazel-bin/link_repro
bazel-bin/link_repro:
	@loader_path/_solib_darwin_x86_64//liblibregular_Udep.so (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2)

Which is the correct location for the regular_dep shared object, although the double slash is a bit suspicious.

Environment info

• Operating System:

macOS Sierra 10.12.5

• Bazel version (output of bazel info release):

release 0.5.2

Have you found anything relevant by searching the web?

This may be the same underlying problem as #507 (similar symptoms, although the cause sounds different). Feel free to close as a duplicate if you think they're the same.

[martinwicke]

This will likely start blocking TF's effort to build more modularly, and if so, will quickly become a priority for us. For now, since it appears to only affect Macs, we can continue working.

[hlopko]

I have a fix in the oven, will try to submit this week.

[hlopko]

And finally submitting.

[gunan]

Great!
which release should we expect this to be in?

[hlopko]

The fix was too late for 0.5.4 so the one after that.