RUNPATH pozornie ignorowane przez Python 3 na RHEL 7.4

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.

— Michael Greenburg
źródło