tensorflow: Problem after installing new version using pip

Click to expand!

Issue Type

Build/Install

Have you reproduced the bug with TF nightly?

Source

binary

Tensorflow Version

2.11 and 2.12

Custom Code

OS Platform and Distribution

Linux mint 20.1

Mobile device

Python version

3.9

Bazel version

GCC/Compiler version

CUDA/cuDNN version

11.8.0 from anaconda / nvidia-cudnn-cu11==8.6.0.163 (from pip)

GPU model and memory

rtx 3070 mobile 8 gb vram, 32 gb ram

Current Behaviour?

After installing using this tutorial https://www.tensorflow.org/install/pip#linux i can’t import tensorflow. Here is an error.

I’ve tried with 2.11, 2.12 TF installed using pip.

If I’m trying to install tf-nightly, then I’ve got another error

Standalone code to reproduce the issue

import tensorflow as tf

Relevant log output

>>> import tensorflow
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/daddywesker/anaconda3/envs/stdfex/lib/python3.9/site-packages/tensorflow/__init__.py", line 37, in <module>
    from tensorflow.python.tools import module_util as _module_util
  File "/home/daddywesker/anaconda3/envs/stdfex/lib/python3.9/site-packages/tensorflow/python/__init__.py", line 36, in <module>
    from tensorflow.python import pywrap_tensorflow as _pywrap_tensorflow
  File "/home/daddywesker/anaconda3/envs/stdfex/lib/python3.9/site-packages/tensorflow/python/pywrap_tensorflow.py", line 26, in <module>
    self_check.preload_check()
  File "/home/daddywesker/anaconda3/envs/stdfex/lib/python3.9/site-packages/tensorflow/python/platform/self_check.py", line 63, in preload_check
    from tensorflow.python.platform import _pywrap_cpu_feature_guard
ImportError: /home/daddywesker/anaconda3/envs/stdfex/lib/python3.9/site-packages/tensorflow/python/platform/../../libtensorflow_cc.so.2: undefined symbol: _ZNK10tensorflow8OpKernel11TraceStringB5cxx11ERKNS_15OpKernelContextEb

About this issue

Original URL
State: closed
Created a year ago
Comments: 28

Most upvoted comments

Thanks for debugging the issue! It seems this is a new side effect that arises when you mix global TF installations with installs in a virtual environment. We recommend all TF installs should be done in a venv to prevent these contagions.

TF has a large C++ component that needs to be shipped with the wheel in order for users to use it. We could have localized the shared lib (.so file) to within the wheel (like smaller .sos are), but libtensorflow_framework is needed also if you want to do TF from other languages. So, for example, if you want to use TF from, say, Rust, you’d install the wheel, then tell your build process to link against this .so (and a few others).

There is no standard channel for distributing C++ artifacts, so it was decided to distribute them via the wheel and a GCS bucket. Recently, to reduce the number of builds, the GCS bucket was discontinued, so now users can get the shared objects only via the wheel.

Overall, this issue points to a new debugging item for similar issues: we should ask users to confirm whether they have global TF installations or everything is in a venv.

mihaimaruseac on Jul 24, 2023