Thank you for your post. We noticed you have not filled out the following field in the issue template. Could you update them if they are relevant in your case, or leave them as N/A? Thanks.
Have I written custom code
OS Platform and Distribution
TensorFlow installed from
TensorFlow version
Bazel version
CUDA/cuDNN version
GPU model and memory
Exact command to reproduce

sigh for this kind of issue, it really doesn't matter but for the sake of automation, here I go:

• 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): Arch Linux
• TensorFlow installed from (source or binary): source
• TensorFlow version (use command below): 1.4.1
• Python version: 3.6
• Bazel version (if compiling from source): 0.9.0
• GCC/Compiler version (if compiling from source): 7.2.1
• CUDA/cuDNN version: 9.1.85/7.0.5
• GPU model and memory: 1080 TI with 11711807488 bytes
• Exact command to reproduce: N/A

I think there was a similar question but can't seem to find it.

@gunan what's our position here?

Eventually, we would like to enable this.
Maybe we can control this using environment variables just like we do for MKL?

@drpngx could it be this question I posted a while ago #8403 ? I'd be very interested as well if any progress is made on this!

@danbarnes333 yes that's right on.

Maybe a stepping stone would be to allow people to link against the system protobuf during the configure step, via some environment variable or a configure flag. I think that would be a good contribution.

We should also consider, at some point, distributing pip packages that are dependent on a libprotobuf package.

CC @allenlavoie @skye

This would be useful to us as well. We are currently stuck in a situation where the protobuf symbols in libtensorflow_framework.so are being clobbered by symbols in a custom libprotobuf from a different API revision that is being loaded to support the operations of our custom backend to TensorFlow.

In other words, we have this library dependency tree right now:

• _pywrap_tensorflow_internal.so
  • libtensorflow_framework.so (contains protobuf 3.4 library)
  • our_high_level_library.so
    • our_device_library.so
      • libprotobuf.so (version 3.x)

We found a workaround by forcing bazel to use a protobuf version that matched the one used elsewhere on the system. Here is a patch that will force usage of the 3.4.0 library, but one can also point to any other archive tag on github.
patch.tar.gz

@RichDubielzig that is what we have been doing, as well as hiding more symbols in the tensorflow shared library, and has been working ok. However @drpngx mentioned on my original issue that this isnt completely safe unless I misunderstood (about halfway down #8403) but perhaps things have changed since then. Either way simply building against the system protobuf would be great.

@RichDubielzig Do you mind to tell more detail about how to use the file you gave? Like where should I put it and how can I make it work? Thanks alot.

If this ever gets picked up you'll probably need protobuf to enable dynamic linking as well - protocolbuffers/protobuf#8291

This issue is stale because it has been open for 180 days with no activity. It will be closed if no further activity occurs. Thank you.

This is definitely still valid.

This issue is stale because it has been open for 180 days with no activity. It will be closed if no further activity occurs. Thank you.

It's still relevant.

This issue is stale because it has been open for 180 days with no activity. It will be closed if no further activity occurs. Thank you.

It's still a problem.