Building a shared libary

[Keno]

Is there a way to ask the build system to build a shared library that one can link a program written using the C++ API against? My apologies for this simple question, but I am very unfamiliar with this build system.

[absalomedia]

Bazel has an option to build a shared object out of a binary: http://bazel.io/docs/be/c-cpp.html ,namely linkshared. It can be done, but I'm a little unsure if the Tensorflow build system can do it out of the box.

I'm currently running experiments on Travis with Tensorflow to see how it reacts/accommodates to C shared object.

[aliasaila]

This naive build rule produces a shared library that seemingly made it as far as loading the inception model (via the C API), before crashing.

cc_binary(
    name = "libtensorflow.so",
    copts = tf_copts(),
    linkshared = 1,
    linkopts = [
        "-lpthread",
        "-lm",
    ],
    deps = [
        ":cc_ops",
        "//tensorflow/core:kernels",
        "//tensorflow/core:tensorflow",
    ],
)

Program received signal SIGSEGV, Segmentation fault.
tensorflow::NodeBuilder::NodeOut::NodeOut (i=0, n=0x23c1620, 
    this=0x7fffffffc3d0)
    at tensorflow/tensorflow/core/graph/node_builder.h:39
#0  tensorflow::NodeBuilder::NodeOut::NodeOut (i=0, n=0x23c1620, 
    this=0x7fffffffc3d0)
    at tensorflow/tensorflow/core/graph/node_builder.h:39

[jimfleming]

I pieced together a lot of the scattered information on compiling for C++ and wrote it up: https://medium.com/@jimfleming/loading-a-tensorflow-graph-with-the-c-api-4caaff88463f

Hopefully it will be helpful for someone here. I'm going to try a shared library next to see if I can reduce the build size.

[absalomedia]

I'm more looking at Tensorflow as a shared library to make it more code / platform agnostic to talk to (my platform of choice being PHP/HHVM). There's already bindings for Go here: https://github.com/chai2010/tensorflow which seems similar to your ideas @jimfleming

So I think we might be able to get there. Just may take a bit of rework

[nbenhaim]

@jimfleming have you gotten a shared library working? I tried @aliasaila's suggestion and also got seg fault when trying to run my program. When compiling with the cc_library option, I do get a .so file, but it is very small, and when compiling I have undefined references. So I know something isn't set up correctly. thanks

[absalomedia]

@nbenhaim Tensorflow:core has some dependencies set as libstatic in the Bazel build file (https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/BUILD) which would explain why you're missing references (http://bazel.io/docs/be/c-cpp.html) :

The linkstatic attribute has a different meaning if used on a cc_library() rule. For a C++ library, linkstatic=1 indicates that only static linking is allowed, so no .so will be produced.

[jimfleming]

@nbenhaim Yes and no. I can compile the .so using cc_binary + linkshared and I can load the graph from the host language using the C API and an FFI interface. The values I get back from the graph don't make sense though. I'll be playing with it over Thanksgiving and will definitely publish my results here.

[aliasaila]

@nbenhaim Initially I was following the label_image example and using tensorflow::ops::ReadFile to load the image file. Unfortunately I couldn't pinpoint the issue (the debug version of the shared lib was too big to load). To bypass the issue I added code to load and populate the input Tensor outside of TensorFlow, and that was successful.

[davidzchen]

FYI, there is a similar discussion on building a shared library in #5. Perhaps you can combine efforts?

[nbenhaim]

@jimfleming how are you linking your compiled so file with your project? I am able to compile executables and .so files from within the tensorflow build environment, but when I take the compiled so file and link it into my project with my own cmake build environment, the resulting program does compile but crashes on startup at some Tensorflow Kernel related method. How can I see what compile options bazel is using? I suspect there is some sort of incompatibility there. Thanks

[jimfleming]

I'm building the .so as I described above—now I don't need the TensorFlow environment. Then renaming the .so to .dylib (they're different but the host language doesn't know that and I'm on a Mac). Then using the host language's C FFI interface I'm calling into the shared library.

[jimfleming]

@nbenhaim I've managed to load and execute TensorFlow graphs using TensorFlow's C API (I'm not a fan of SWIG). Hopefully this will be useful to you: https://medium.com/jim-fleming/loading-tensorflow-graphs-via-host-languages-be10fd81876f

[vrv]

Nice work @jimfleming!

"This comment in the TensorFlow source makes it sound like it’s optional but it’s not:" -- want to send us a change to fix it, or suggest an improvement? Should we switch 'can' to 'must' ?

[jimfleming]

Thanks!

Sure, I can do that. It'll be a good exercise in learning the contribution process anyways. Yah, it's the "can" that was unclear, "must" would be better.

EDIT: https://tensorflow-review.googlesource.com/1180

[adamcrume]

I would love if @jimfleming's libtensorflow.so rule were included in the TensorFlow repo. Can we do that? Patching source locally is less than ideal, and setting up a new Bazel workspace that depends on the TensorFlow one is nearly impossible because of several Bazel bugs/missing features.

[martinwicke]

If someone sends us a PR, I'd be very happy to merge it.

[vrv]

the shared library was added a while ago, yay!

[formath]

@jimfleming Thanks for your blog "loading-a-tensorflow-graph-with-the-c-api". I build a static lib on macOS not using bazel. When linking my custom c++ prediction code, some errors occur. Can you give me some helps? #13306