cc_library with .dylibs

[XperielIndigo]

Hi,

I'm trying to include ffmpeg in my project. To build it I use their configure/make compilation system which builds lib[name].[version].dylib files for Mac OS X.

cc_library apparently doesn't allow .dylib files in srcs. My initial workaround was to manually add the dylibs to data and use -L and -l commands in linkopts. However, this doesn't work when depending on the cc_library from another package (the -L command cannot find the directory).

How do I use .dylibs in cc_libraries?

Thanks
Indigo

[kchodorow]

I can't reproduce, this seems to work for me:

cc_binary(
    name = "main_thing",
    srcs = ["main_thing.cc", "floperator.3.dylib"],
)

And:

$ bazel build :main_thing
INFO: Found 1 target...
Target //:main_thing up-to-date:
  bazel-bin/main_thing
INFO: Elapsed time: 0.479s, Critical Path: 0.09s

Can you give more details about what's in your BUILD file and the error you're getting?

[XperielIndigo]

I just put it in an example repo. If you clone that and run bazel test ... you should see the failure https://github.com/XperielIndigo/FFmpegBazelIssue

[kchodorow]

Thanks, I'll give it a try.

[ulfjack]

This change should have allowed .dylib in srcs; are you at a more recent
rev?
95abc4d

On Tue, Sep 1, 2015 at 8:44 PM, Kristina [email protected] wrote:

Thanks, I'll give it a try.

—
Reply to this email directly or view it on GitHub
#407 (comment).

[kchodorow]

I've found one issue (https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/cpp/LinkCommandLine.java#L910 needs to be "(^lib|\\.(so|dylib)$)"), but it still gives me an error when the binary is run because the library isn't in the system library path. Still working on it.

[XperielIndigo]

Great, thanks Kristina. When I was running it, it wasn't complaining in the bazel analyze phase, it was failing when trying to do -lavformat.56.dylib

[kchodorow]

Okay, the other problem is that osx_gcc_wrapper.sh isn't fixing the install name correctly. I think I have a fix for that.

[kchodorow]

I've got a change to make osx_gcc_wrapper fix the shared library paths:

$ otool -L bazel-bin/test
bazel-bin/test:
    /Users/kchodorow/gitroot/FFmpegBazelIssue/lib/mac/lib/libavcodec.56.dylib (compatibility version 56.0.0, current version 56.59.100)
    /Users/kchodorow/gitroot/FFmpegBazelIssue/lib/mac/lib/libavdevice.56.dylib (compatibility version 56.0.0, current version 56.4.100)
    /Users/kchodorow/gitroot/FFmpegBazelIssue/lib/mac/lib/libavfilter.5.dylib (compatibility version 5.0.0, current version 5.40.100)
    /Users/kchodorow/gitroot/FFmpegBazelIssue/lib/mac/lib/libavformat.56.dylib (compatibility version 56.0.0, current version 56.40.101)
    /Users/kchodorow/gitroot/FFmpegBazelIssue/lib/mac/lib/libavutil.54.dylib (compatibility version 54.0.0, current version 54.31.100)
    /Users/kchodorow/gitroot/FFmpegBazelIssue/lib/mac/lib/libswresample.1.dylib (compatibility version 1.0.0, current version 1.2.101)
    /Users/kchodorow/gitroot/FFmpegBazelIssue/lib/mac/lib/libswscale.3.dylib (compatibility version 3.0.0, current version 3.1.101)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

However, this doesn't help, because the dylib inputs use system paths to refer to each other:

$ otool -L lib/mac/lib/libavfilter.5.dylib 
lib/mac/lib/libavfilter.5.dylib:
    /usr/local/lib/libavfilter.5.dylib (compatibility version 5.0.0, current version 5.40.100)
    /usr/local/lib/libswscale.3.dylib (compatibility version 3.0.0, current version 3.1.101)
    /usr/local/lib/libavformat.56.dylib (compatibility version 56.0.0, current version 56.40.101)
    /usr/local/lib/libavcodec.56.dylib (compatibility version 56.0.0, current version 56.59.100)
...

I could go through recursively and change all inputs to refer to each other if possible, but I'm not sure if that's the right solution. Anyone have any thoughts?

[tfboyd]

Symbolic linking everything to /usr/local/lib looks to be working but that seems crazy and maybe related to SIPs. Who knows but hopefully the libraries are also included in the pip. Referencing the cc_library of .so files worked perfect on linux. I guess I wonder is the a Bazel problem or a pure OSX problem that clang would have without Bazel being involved.

We seem to have this same issue in TensorFlow trying to link to the MKL. It works fine in Linux but trying to build with the dylib files fails. We will open a bug internally and ask for help as the MKL adds a large performance boost to our community and especially on Macs where the video card is normally not well supported for ML. We expected this file to work just like it does for .so files. It also makes it hard for partners to contribute and thus the integration falls to us to deal with. :-(

I get similar errors to others I see on the internet:

 command 
  (cd /private/var/tmp/_bazel_tobyboyd/821f089e97475487e2bd5e7d58796143/execroot/tensorflow && \
  exec env - \
    PATH=/usr/local/opt/llvm/bin:/usr/local/opt/coreutils/libexec/gnubin:/Users/tobyboyd/google-cloud-sdk/bin:/usr/local/git/current/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/X11/bin:/Applications/Wireshark.app/Contents/MacOS \
    PYTHON_BIN_PATH=/usr/bin/python \
    PYTHON_LIB_PATH=/Library/Python/2.7/site-packages \
    TMPDIR=/var/folders/b4/0wpkk3gx7xq32w9q948sglf40095tj/T/ \
  /bin/bash -c 'source external/bazel_tools/tools/genrule/genrule-setup.sh; bazel-out/host/bin/tensorflow/python/gen_nn_ops_py_wrappers_cc @tensorflow/python/ops/hidden_ops.txt 1 > bazel-out/local-opt/genfiles/tensorflow/python/ops/gen_nn_ops.py'): com.google.devtools.build.lib.shell.AbnormalTerminationException: Process terminated by signal 6.
dyld: Library not loaded: @rpath/libmklml.dylib
  Referenced from: /private/var/tmp/_bazel_tobyboyd/821f089e97475487e2bd5e7d58796143/execroot/tensorflow/bazel-out/host/bin/tensorflow/python/gen_nn_ops_py_wrappers_cc
  Reason: image not found

licenses(["restricted"])  # MPL2, portions GPL v3, LGPL v3, BSD-like     TODO

config_setting(
    name = "using_mkl",
    values = {
        "define": "using_mkl=true",
    },
    visibility = ["//visibility:public"],
)

load(
    "//third_party/mkl:build_defs.bzl",
    "if_mkl",
)

cc_library(
    name = "intel_binary_blob",
    srcs = if_mkl([
        "libdl.dylib",
        "libmklml.dylib",
        "libiomp5.dylib",
    ]),
    includes = ["."],
    visibility = ["//visibility:public"],

# from bazel-bin
tobyboyd-macbookpro:_U_S_Sthird_Uparty_Smkl_Cintel_Ubinary_Ublob___Uthird_Uparty_Smkl tobyboyd$ otool -L libmklml.dylib 
libmklml.dylib:
	@rpath/libmklml.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
tobyboyd-macbookpro:_U_S_Sthird_Uparty_Smkl_Cintel_Ubinary_Ublob___Uthird_Uparty_Smkl tobyboyd$ 

[gunan]

Ping!
Any updates here?
I am also running into this on macos

[gunan]

To describe the issue I and @tfboyd is seeing further:

We have a cc_binary we build, which we then use with a genrule.
These binaries have a dependency to a prebuilt dylib. When running the genrule, we run into the issue @tfboyd posted. It all seems to work fine on linux

[hlopko]

Quick update, I think the problem is that https://github.com/bazelbuild/bazel/blob/master/tools/cpp/osx_cc_wrapper.sh.tpl only assumes .so extension when updating the install. Also mentioned in #1576. It didn't work for precompiled libraries before, but that was fixed in f426544. IIUC, changing osx_cc_wrapper.sh and osx_cc_wrapper.sh.tpl to fix .dylibs in addition to .sos will resolve this issue.

[vade]

Hi - gentle ping from Mac Tensorflow user wanting to have MKL support out of the box, and this issue appears to be a blocker.

Im unfamiliar with the tooling here, otherwise id be happy to help. Thank you in advance for any work towards a solution to this.

[hlopko]

Thanks for letting me know, I will try to fix it this week.

[vade]

Can this be re-opened - was rolled back above ^^ still blocking Tensorflow activity - apologies for appearing pushy in advance! Very appreciated!

[hlopko]

No problem thank's for reminding me. The fix is trivial, just need to find time to resubmit.