Produce static libs from tensorflow_cc and tensorflow_framework

Question

As far as I understand using bazel I can only produce libtensorflow_cc.so and libtensorflow_framework.so. I need to produce static libs that are position independent (-fPIC) because I'll link them to a dynamic lib of my own later.

I found this answer which suggest the use of a Makefile included in the project. I successfully used it to replace the libtensorflow_cc.so but what can I do to replace libtensorflow_framework.so?

Answer 1

Not an actual answer, but too long for a comment.

I managed to do something like what you mention using Bazel on Windows. In particular, I wanted to make a single wrapper DLL with one or two headers (limited in functionality) that I could move around easily. I'll write a summary of the things that I did; it's rather convoluted an customized for our needs, but maybe you find something useful.

• I pass --config=monolithic to the bazel build command (besides any other option that you need). That will avoid modularizing the library and thus remove the dependency to a libtensorflow_framework.so (see tools/bazel.rc).
• The goal that I build is not any of the ones in the TensorFlow repository. Instead, I add a very small program that uses my wrapper as a new Bazel target (a C++ file plus my headers headers and a BUILD file). So all of TensorFlow had to be compiled beforehand in order to compile this final dummy program.
• When I get that done, I take advantage of the fact that Bazel does already compile every subgoal as a static library. I check a file under the bazel-bin directory generated for my dummy program goal with a name ending .params - there I find the path of all the static libraries that were used to compile it.
• I copy all of these intermediate static libraries to somewhere else. Also, I copy a bunch of headers I will need to compile my final wrapper (TensorFlow own's, but also Eigen, Protobuf and Nsync now too). I put all of this in a build area I have prepared before.
• I use NMake Makefile to produce my custom DLL, using the static libraries, the copied headers and my own thin wrapper.

And that's about it, I think. I have an ugly Bash script I run on MSYS2 that does everything for me. Usually with every new release I need to tweak one or two things (some option in the configure script, some additional headers I need to copy, etc.), but I do get it to work in the end. It's quite a lot of fiddling though, so I'm not necessarily saying you should use the same approach (but feel free to ask for details about any step if you want).