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

问题描述

我必须在当前的Ubuntu（12.04）上编译一个程序。然后这个程序应该运行在使用CentOS的集群上（2.6.18）。不幸的是，我无法直接在群集上编译。如果我只是在没有任何改变的情况下编译和复制程序，我会收到错误消息内核太旧。

据我了解，原因不在于内核版本，而在于编译时使用的libc版本。所以我试图编译我的程序，动态链接集群中的libc，并静态链接其他所有内容。

研究

b

关于这方面的问题已经有很多问题，但没有一个答案真的对我有用。所以这里是我对这个话题的研究：

• 这个问题解释了内核过时消息的原因


• 这个问题类似，但更专业化，没有答案


• 建议静态链接这里没有工作，因为libc在集群上太旧了。一个答案也提到了使用旧的libc构建，但没有解释如何做到这一点。 你不应该静态链接libc
• 
  
• 显然 it 是可能的，以使用选项 -rpath 但这并不适用于我（见下文）



当前状态

我将以下文件从集群复制到目录 / 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

t上的ldd的输出他编译的二进制文件是

  mybin：/path/to/copied/libs/libc.so.6：version'GLIBC_2.14 '找不到（需要mybin）
 mybin：/path/to/copied/libs/libstdc++.so.6：未找到'GLIBCXX_3.4.15'版本（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时，它会返回不是动态可执行文件，并在上述相同的两个错误中运行二进制结果。它看起来还有其他库（linux-vdso.so.1，ld-linux-x86-64.so.2和libm.so.6）。我应该使用旧版本吗？

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

• 这在这里甚至是正确的方法吗？


• 如果是：我如何正确链接旧的libc？

解决方案

请参阅此答案。

这是甚至正确的方法吗？

否：您的链接命令不能使用glibc的不匹配版本。您从 new （系统安装）使用了 crt0.o 和 ld-linux.so ）libc，但是从旧的（从集群复制的）libc中删除 libc.so.6 。这只是不会起作用。

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".

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.

Research

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:

• 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)

Current state

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

and am compiling with the options -nodefaultlibs -Xlinker -rpath=/path/to/copied/libs -Wl,-Bstatic,-lrt,-lboost_system,-lboost_filesystem -Wl,-Bdynamic,-lc,-lstdc++,-lgcc_s

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)

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:

• Is this even the correct approach here?
• If yes: how do I link the old libc correctly?

解决方案

See this answer.

Is this even the correct approach here

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屋！