Request for distribution of prebuilt headers and libraries

[kmalakoff]

I have been working on a port of tensorflow to Node.js and when the node module is installed, it currently requires a time consuming build step and the user to set up bazel. Here is how I trigger the install: script and vendor folder structure.

As part of an investigation into this, I noticed that as part of installing the python package, tensorflow is distributing the libraries...for example inside of https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-0.11.0-py2-none-any.whl.

I was wondering if the tensorflow team would be open to building and hosting the headers and libraries for a variety of platforms and configurations (eg. cuda, no cuda) that can be downloaded and directly linked to in C++?

FYI: I have also opened an issue with bazel (bazelbuild/bazel#2206) about their plans for prebuilt asset distribution tooling.

[gunan]

CC @asimshankar

[asimshankar]

I am planning on distributing the library and header file for the TensorFlow C API, which is intended for building other language bindings on (Go, Java, Rust, Haskell etc.). Hopefully, that will be sufficient for the Node.js port as well? Our intention is for the C API to be sufficient for building language bindings (as in the HOWTO.

I wasn't planning on binary releases for C++, as it may be hard to guarantee ABI compatibility.

I have to work on some guarantees around libc version compatibility, but I started on tentative scripts to build releases for linux and OS X.

Will update this issue when we start producing those binary artefacts along with the release.

[kmalakoff]

@asimshankar sounds good. If both could be distributed, I would use the C++ API.

I have performed some basic steps of implementing a port to Node.js with both the C and C++ APIs. Definitely, C++ is a much better API when you can use it (I could when using Nan for Node.js, but probably more of an exception in porting approaches) and it looks like the team might be starting with C++ and then porting back to C so it might be more complete sooner, but since we are talking about official headers and libraries distributed for official releases, C++ and C feature sets should hopefully be in sync at each release.

I'm not sure how header and library dependencies for eigen, protobuf, etc would be provided, but I would need a way to ensure I was using the same versions as tensorflow was built with.

I did raise an issue to bazel and am a bit surprised about coming back to C / C++ after 15+ years away that there isn't a common package manager for this ecosystem. However you decide to distribute these, it would be great to be as low friction as possible to use including setting up build environments and managing external library dependencies.

I'm really looking forward to this!

[asimshankar]

FYI, with TensorFlow 1.0 we've started releasing binary artifacts for the TensorFlow C library in URLs of the form: https://storage.googleapis.com/tensorflow/libtensorflow/libtensorflow-${TF_TYPE}-${OS}-${ARCH}-${VERSION}.tar.gz

For example:

• https://storage.googleapis.com/tensorflow/libtensorflow/libtensorflow-cpu-darwin-x86_64-1.0.0.tar.gz
• https://storage.googleapis.com/tensorflow/libtensorflow/libtensorflow-gpu-linux-x86_64-1.0.0.tar.gz

Currently, we only build releases for linux and darwin for x86_64. These are built with the BUILD rules in tensorflow/tools/lib_package
so can be built for other platforms as well.

For C++ we are trying to carve out an minimal API that doesn't depend on a lot of internal headers and are trying to package that. No ETA yet (CC @skyewm)

[martinwicke]

I will close this issue. Please open a new one if there are aspects that are not solved by the binaries we currently distribute.

[megazone87]

@asimshankar Hi, is c++ api library ready now? Or what's the current state? I am eager to use one TF c++ library just for inferences on server(I know libtensorflow_inference.so for Android).

[asimshankar]

@songmeixu : Nope we haven't had the chance to create prebuilt distributions of all the C++ headers, so those have to be manually built and packaged from source right now.