Include C and C++ APIs with binary distributions

[peastman]

System information

• Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
• OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Any
• TensorFlow installed from (source or binary): see below
• TensorFlow version (use command below): Any
• Python version: Any
• Bazel version (if compiling from source):
• GCC/Compiler version (if compiling from source):
• CUDA/cuDNN version:
• GPU model and memory:
• Exact command to reproduce:

When you install a precompiled Tensorflow binary with pip or conda, it doesn't include the C and C++ interfaces. To use it from those languages, you need to compile Tensorflow for source and build a special version of it that includes the needed API (see #2412). I suggest including them in the standard binaries. This would have multiple benefits.

First, it would make development in other languages much easier. You could just pip install tensorflow and link against the library it installed. Having to build a special version of Tensorflow from source adds an unnecessary barrier to getting started.

Second, it would eliminate a problem that so far I've been unable to resolve. I want to create a C++ library that uses Tensorflow. That library will be usable directly from C++, but I'll also use SWIG to create a Python wrapper for it. For example, a user should be able to write Python code to build a Graph, then pass it directly to my library.

That won't work right now, because there are two separate versions of Tensorflow involved, one that Python is linked against and a different one that my library is linked against. When the user is building a Graph in Python, they're working with one Tensorflow library. But when they try to pass it to my library, they're suddenly switching to a completely different copy of Tensorflow, so it doesn't have access to memory allocated by the first copy. I haven't found any solution to this problem.

[angerson]

@gunan Is this in our plans at all?

[gunan]

CC @asimshankar

[asimshankar]

Regarding development with other language bindings: Note that we release binary versions of the C and Java APIs with every TensorFlow releases, so they do not have to be built from source. See: https://www.tensorflow.org/install/install_c and https://www.tensorflow.org/install/install_java
Language bindings maintained by others (C#, Rust, Ruby, Julia etc.) typically link against the released C API artifacts and do not have to build from source.

A note on structure: The way the language bindings are structured is that the core "framework" is in libtensorflow_framework.so and then language specific shared libraries that depend on it (e.g., pywrap_tensorflow.so for Python, libtensorflow.so for C, libtensorflow_jni.so for Java etc.).

We currently do not produce artifacts for the C++ API though. We haven't had the bandwidth to support that yet, though would be great to.

I don't think it would make sense to include all language bindings with the Python pip package, but I do agree that it would be nice to enable your use-case of writing C++ TensorFlow that interoperates with Python. Alas, nobody is actively working on this at the moment. (BTW, just for completeness, I'm sure you've seen how you can write custom ops in C++ and link them with your Python program?).

I'm going to mark this as "Community Support" for now, given that enabling this use case of writing libraries in other languages and mixing those with Python isn't something we (the TensorFlow team) will have the bandwidth to get to or support in the near future (with the exception of writing new TensorFlow operations, which does work).

If there is a lot of interest in this feature, we could reprioritize.

[peastman]

What would be involved in supporting interoperability with other languages? I'm willing to look into it if it's not too difficult, though my knowledge of Tensorflow internals is pretty limited.

I do think there's value in bundling the other APIs with the pip package, since it makes the installation really simple, and then it's guaranteed that every user will have them. For example, this is how Caffe2 handles it: just conda install caffe2, and you have everything needed for development in both Python and C++. They even include a CMake configuration script with it, so you don't even need to worry about where libraries and headers have gotten installed. Just add the line find_package(Caffe2) to your build script, and everything magically works. It would be great if Tensorflow could make its other interfaces similarly easy to use.

[asimshankar]

(Probably worth linking this with #15290)

@peastman : If you're interested, it's probably worth discussing this on the "build" group at https://www.tensorflow.org/community/lists#special_interest_groups
Since there you will find a community of folks interested in figuring out the appropriate packaging story.

Thanks for your interest!

[sarlinpe]

Workarounds are currently possible, e.g. tensorflow_ros links against the pip binaries for C++.

The only limitation is that the current pip binaries are built with the old C++ ABI, while some OS (e.g. Ubuntu 16) build only with the new C++11 ABI. There's a pip bug report about that.
@asimshankar Is this going to be solved at some point ?

[asimshankar]

@skydes : ABI compatibility concerns is one of the reasons why we haven't committed to a binary distribution of the C++ APIs yet. There is some ideas we're exploring so that custom operations and kernels can be written against a stable C API/ABI, but that is in early stages of exploration so no timeline on that yet.

In the mean time, yeah, to link against pre-built libtensorflow_framework.so, you'd have to continue to build against the ABI used by it.

[tensorflowbutler]

As this issue has invited community support, please remove the assignee. Otherwise, remove the community support label. Thank you.

[tensorflowbutler]

As this issue has invited community support, please remove the assignee. Otherwise, remove the community support label. Thank you.