Zbudowałem TensorFlow 1.12 ze źródła przy użyciu Bazel 15.0, Python 3.6.5 i GCC 7.3.0. Wygląda na to, że działa poprawnie, ale kiedy importuję pandasprzed importem tensorflow, używa /lib64/libstdc++.so.6, zamiast tego powiązanego z GCC 7.3.0:
$ python3 -c "import tensorflow, pandas" # no error
$ python3 -c "import pandas, tensorflow"
Traceback (most recent call last):
File "/zapps7/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/python/pywrap_tensorflow.py", line 58, in <module>
from tensorflow.python.pywrap_tensorflow_internal import *
File "/zapps7/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/python/pywrap_tensorflow_internal.py", line 28, in <module>
_pywrap_tensorflow_internal = swig_import_helper()
File "/zapps7/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/python/pywrap_tensorflow_internal.py", line 24, in swig_import_helper
_mod = imp.load_module('_pywrap_tensorflow_internal', fp, pathname, description)
File "/apps/python/3.6.5/gcc-7.3.0/lib/python3.6/imp.py", line 243, in load_module
return load_dynamic(name, filename, file)
File "/apps/python/3.6.5/gcc-7.3.0/lib/python3.6/imp.py", line 343, in load_dynamic
return _load(spec)
ImportError: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /zapps7/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/zapps7/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/__init__.py", line 24, in <module>
from tensorflow.python import pywrap_tensorflow # pylint: disable=unused-import
File "/zapps7/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/python/__init__.py", line 49, in <module>
from tensorflow.python import pywrap_tensorflow
File "/zapps7/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/python/pywrap_tensorflow.py", line 74, in <module>
raise ImportError(msg)
ImportError: Traceback (most recent call last):
File "/zapps7/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/python/pywrap_tensorflow.py", line 58, in <module>
from tensorflow.python.pywrap_tensorflow_internal import *
File "/zapps7/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/python/pywrap_tensorflow_internal.py", line 28, in <module>
_pywrap_tensorflow_internal = swig_import_helper()
File "/zapps7/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/python/pywrap_tensorflow_internal.py", line 24, in swig_import_helper
_mod = imp.load_module('_pywrap_tensorflow_internal', fp, pathname, description)
File "/apps/python/3.6.5/gcc-7.3.0/lib/python3.6/imp.py", line 243, in load_module
return load_dynamic(name, filename, file)
File "/apps/python/3.6.5/gcc-7.3.0/lib/python3.6/imp.py", line 343, in load_dynamic
return _load(spec)
ImportError: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /zapps7/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so)
Failed to load the native TensorFlow runtime.
See https://www.tensorflow.org/install/errors
for some common reasons and solutions. Include the entire stack trace
above this error message when asking for help.
-Wl,--enable-new-dtags,-rpath,/apps/gcc/7.3.0/lib64Upewniłem się podczas budowania do użycia i potwierdziłem, że RUNPATH jest rzeczywiście ustawiony:
$ readelf -d /apps/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../../_solib_k8/_U_S_Stensorflow_Spython_C_Upywrap_Utensorflow_Uinternal.so___Utensorflow:$ORIGIN/../../_solib_k8/_U@mkl_Ulinux_S_S_Cmkl_Ulibs_Ulinux___Uexternal_Smkl_Ulinux_Slib:$ORIGIN/:$ORIGIN/..:/apps/gcc/7.3.0/lib64]
$ ldd /apps/python-3.6.5-tensorflow/1.12.0/lib/python3.6/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so | grep libstdc++
libstdc++.so.6 => /apps/gcc/7.3.0/lib64/libstdc++.so.6 (0x00007f82c9711000)
Wydaje się dziwne, że pomimo tego, że lddznajduje to, co jest właściwe libstdc++.so.6(więc prawdopodobnie nie jest duplikatem tego problemu ), w tych okolicznościach używa się niewłaściwego. LD_LIBRARY_PATHi LD_PRELOADnie są ustawione, a ld.sostrona man pokazuje, że RUNPATH powinien mieć zatem pierwszeństwo. Może się zdarzyć, że nie rozumiem, co powinno się wydarzyć - mam wrażenie, że ELF nieobecny LD_LIBRARY_PATHi najwyższy organ decyduje o tym, gdzie należy przeszukiwać biblioteki, i że wszystko, co widzi, powinno być dokładnie tym, co jest używane w czasie wykonywania. Czy jestem nieporozumieniem? Czy istnieje realny sposób (tj. NIE tylko niechlujny sposób używania ), aby to naprawić?LD_PRELOADRUNPATHlddLD_LIBRARY_PATH
Jest trochę więcej informacji na temat tego problemu na GitHub , chociaż nie wiem, ile z tego będzie pomocne.
źródło