使用较旧的 libc 编译(未找到版本“GLIBC_2.14") [英] Compile with older libc (version `GLIBC_2.14' not found)

问题描述

我必须在当前的 ubuntu (12.04) 上编译一个程序.然后，该程序应在使用 CentOS 和旧内核 (2.6.18) 的集群上运行.不幸的是，我无法直接在集群上编译.如果我只是编译和复制程序而不做任何更改，我会收到错误消息内核太旧".

I have to compile a program on a current ubuntu (12.04). This program should then run on a cluster using CentOS with an older Kernel (2.6.18). I cannot compile on the cluster directly, unfortunately. If I just compile and copy the program without any changes I get the error message "kernel too old".

按照我的理解，原因与其说是内核版本，不如说是编译时使用的libc版本.所以我尝试编译我的程序，动态链接集群中的 libc 并静态链接其他所有内容.

The way I understood it, the reason for this is not so much the Kernel version, but the version of libc that was used for compilation. So I tried to compile my program dynamically linking the libc from the cluster and statically linking everything else.

研究

在 SO 上已经有很多关于这个的问题，但没有一个答案真的对我有用.所以这是我对该主题的研究:

There are already a lot of questions about this on SO but none of the answers really worked for me. So here is my research on that topic:

• 这个问题解释了Kernel too old消息的原因
• 这个问题 类似但更专业，没有答案
• 按照建议此处静态链接不起作用，因为 libc 是集群上太旧了.一个答案还提到使用旧的 libc 进行构建，但没有解释如何做到这一点.
• 一种方法 是在运行旧操作系统的 VM 中编译.这有效但很复杂.我还读到 你不应该静态链接 libc
• 显然 可以使用选项 -rpath 编译不同的 libc 版本，但这对我不起作用(见下文)

• This question explains the reason for the Kernel too old message
• This question is similar but more specialized and has no answers
• Linking statically as proposed here didn't work because the libc is too old on the cluster. One answer also mentions to build using the old libc, but doesn't explain how to do this.
• One way is to compile in a VM running an old OS. This worked but is complicated. I also read that you should not link libc statically
• Apparently it is possible to compile for a different libc version with the option -rpath but this did not work for me (see below)

当前状态

我将集群中的以下文件复制到目录/path/to/copied/libs

I copied the following files from the cluster into the directory /path/to/copied/libs

• libc-2.5.so
• libgcc_s.so.1
• libstdc++.so.6

并且正在使用选项 -nodefaultlibs -Xlinker -rpath=/path/to/copied/libs -Wl,-Bstatic,-lrt,-lboost_system,-lboost_filesystem -Wl,-Bdynamic,-lc,-lstdc++,-lgcc_s

ldd 在编译后的二进制文件上的输出是

The output of ldd on the compiled binary is

mybin: /path/to/copied/libs/libc.so.6: version `GLIBC_2.14' not found (required by mybin)
mybin: /path/to/copied/libs/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by mybin)
linux-vdso.so.1 =>  (0x00007ffff36bb000)
libc.so.6 => /path/to/copied/libs/libc.so.6 (0x00007fbe3789a000)
libstdc++.so.6 => /path/to/copied/libs/libstdc++.so.6 (0x00007fbe37599000)
libgcc_s.so.1 => /path/to/copied/libs/libgcc_s.so.1 (0x00007fbe3738b000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbe37bf3000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbe37071000)

我对这个错误有些困惑，因为它使用了正确的路径(即集群中的 libc)，但仍然抱怨缺少 glibc 版本.在集群上运行 ldd 时，它返回 not a dynamic executable 并运行二进制文件会导致上述两个相同的错误.看起来还包括其他库(linux-vdso.so.1、ld-linux-x86-64.so.2 和 libm.so.6).我也应该使用旧版本吗?

I'm somewhat confused by the error, because it uses the correct path (i.e. the libc from the cluster) but still complains about a missing glibc version. When running ldd on the cluster it returns not a dynamic executable and running the binary results in the same two errors mentioned above. It also looks like there are other libraries included (linux-vdso.so.1, ld-linux-x86-64.so.2 and libm.so.6). Should I use the older versions for those as well?

所以现在我有两个主要问题:

So now I have two main questions:

• 这甚至是正确的方法吗?
• 如果是:如何正确链接旧的 libc?

推荐答案

请参阅 this 答案.

这甚至是正确的方法吗

否:您不能像链接命令那样使用 mismatched 版本的 glibc.您使用 new(系统安装的)libc 中的 crt0.o 和 ld-linux.so，但是 libc.so.6 来自旧的(从集群复制)libc.那是行不通的.

No: you can't use mismatched versions of glibc as your link command does. You used crt0.o and ld-linux.so from new (system-installed) libc, but libc.so.6 from an old (copied from cluster) libc. That is just not going to work.

这篇关于使用较旧的 libc 编译(未找到版本“GLIBC_2.14")的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！