docker - 构建tensorflow 2.2.0 pip wheel文件，用于CentOS系统(旧libc)

Question

介绍:
我必须使用动态链接的cuda库(特别是cudart.so)创建Tensorflow 2.2.0的pip wheel。为此，我目前正在使用tensorflow-dev docker镜像。
我能够构建tf wheel文件，并且能够在构建容器中安装和使用它。
问题:
问题是在CentOS服务器中导入生成的wheel文件时，出现以下错误:

ImportError: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /home1/private/mavridis/Vineyard/tensorflowshared/test/lib64/python3.6/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so)

环顾四周后，问题是由使用较新的libc的构建容器引起的:

ldd --version
ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27

与旧版本的CentOS相比:

ldd --version
ldd (GNU libc) 2.17

预期行为:
已经尝试了'vanilla'tenorflow 2.2.0版本，没有问题，请使用pip安装:

pip install tensorflow==2.2.0

我希望自己的构建也能正常工作。
因此，我假设有一些配置选项或docker配置，以允许我在CentOS设置中使用docker内置的wheel文件，就像pip安装的版本一样。由于打算将这个wheel文件部署到我无法控制的设置中，因此涉及备用OS和/或libc替换的解决方案不适用。
构建配置:
在构建期间，我使用以下配置/命令行:

export TF_NEED_CUDA=1
export TF_USE_XLA=0
export TF_SET_ANDROID_WORKSPACE=0
export TF_NEED_OPENCL_SYCL=0
export TF_NEED_ROCM=0
bazel build --config=opt --config=cuda --output_filter=DONT_MATCH_ANYTHING --linkopt=-L/usr/local/cuda/lib64 --linkopt=-lcudart --linkopt=-static-libstdc++ //tensorflow/tools/pip_package:build_pip_package

关于使用的选项:
--output_filter = DONT_MATCH_ANYTHING:静音警告
--linkopt = -L / usr / local / cuda / lib64 --linkopt = -lcudart:cudart.so的动态链接
--linkopt = -static-libstdc++:静态链接libstc++作为libstc++也会导致libc错误，但是这对于libm是不可能的

Answer 1

I expected my own build to also work.

这种期望是(显然)不正确的。您的程序或库从GLIBC中需要的符号取决于您所调用的函数。
考虑以下程序:

int main() { exit(0); }

在GLIBC-2.30系统上编译/链接时，该程序仅取决于 GLIBC_2.2.5(因为它不调用任何较新的符号)。
现在稍微更改程序:

int main() { gettid(); exit(0); }

再次编译/链接它，突然之间该程序现在需要 GLIBC_2.30(因为 gettid()被添加到GLIBC的位置)，并且在具有较旧GLIBC的任何系统上均无法使用。

So i assume there is some configuration option or docker configuration

当然:您的Docker镜像必须具有不比目标系统新的GLIBC，即GLIBC-2.17。您当前的图片包含GLIBC-2.27(或更高版本)。
您需要一个不同的Docker镜像，并且您可能必须自己构建它，因为GLIBC-2.17是 over 7 years old，并且比TensorFlow早了很多年。
更新:

What i don't understand is how come the pip tensorflow package (which i assumed was build with the docker image i am using) works with CentOS?

它偶然地起作用，就像我的第一个程序可以在CentOS上运行一样，而第二个程序却不能。

In short i wanted to generate a pip package that would work on 'any' linux/libc version

这是一个不可能实现的目标:Linux早于GLIBC，并且不可能构建一个可以在不包含GLIBC的Linux发行版和包含GLIBC的发行版上工作的单个程序包。
您必须在某处画一条线。 tensorflow-dev docker image的开发人员在GLIBC-2.27处划界。基于此镜像构建的软件包应在2.27或更高版本的任何系统上都可以使用，并且可能(但不完全保证)在较旧的系统上可以使用。

just like the pip installed version.

您声称pip安装版本没有“仅GLIBC-xx或更高版本”的要求，但事实并非如此。我有99.9％的把握至少需要GLIBC-2.14。
要查找软件包要求的GLIBC版本，请运行以下命令:

readelf -WV _pywrap_tensorflow_internal.so | grep GLIBC_

I assumed, the pip installed version was built using the publicly available tensorflow-devel docker image.

那很有可能。就像我说的那样，它恰好可以在CentOS上运行，但是细微的更改可能使其不再起作用。
更新2:

So running the readelf command as you suggested, does show the most recent required versions to be: - pip version: GLIBC_2.12 - mine : GLIBC_2.27 So from what i understand the pip version uses an older version even from CentOS, which explains why it works.

它不“使用”较旧的版本，而是使用可用的任何版本。
它需要最低版本2.12，而您的构建需要最低版本2.27。

How do they achieve this? Do they use a different image that has an older libc? If so, where can i get it? Or do they use the public image, but build with some bazel flag, that 'limits' symbols to the ones contained up to libc 2.12?

您仍然没有得到它。
程序所需的版本取决于您所调用的函数。在我的示例程序中，如果我仅调用 exit，则我的程序需要版本2.2.5，但是如果我也调用 gettid，则我的程序需要版本2.30。 注意:这两个程序是在具有相同标志的同一系统上构建的。
因此，没有:他们(很可能)没有使用其他Docker镜像，也没有使用“魔术”淡褐色标志。他们只是碰巧不调用任何需要GLIBC版本> 2.12的函数，而您做到了。
附言您可以找到哪些符号导致构建中的“不良”依赖关系，如下所示:

readelf -Ws  _pywrap_tensorflow_internal.so | egrep 'GLIBC_2.2[0-9]'
readelf -Ws  _pywrap_tensorflow_internal.so | egrep 'GLIBC_2.1[89]'

这将产生类似于(使用第二个程序)的输出:

readelf -Ws a.out | egrep 'GLIBC_2.[23][0-9]'
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND gettid@GLIBC_2.30 (2)
    48: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND gettid@@GLIBC_2.30

上面的输出显示，二进制文件从GLIBC 2.20或更高版本中唯一需要的符号是 gettid。