【发布时间】:2019-01-13 22:11:17
【问题描述】:
我相信其他 Fedora 28 用户会知道,操作系统的 glibc 最近更新为 glibc 2.27。除了许多其他功能之外,2.27 还添加了 logf() 和 powf() 的新实现。这导致我的应用程序无法在具有较旧 glibc(例如 Debian)的发行版上运行。在 Debian 上调用应用程序时,会产生以下错误:
- ... libm.so.6 版本
GLIBC-2.27未找到(./app_name 要求)
我使用以下过程将符号跟踪到 logf 和 powf:
objdump -T ./app_name | grep GLIBC_2.27
它给出了以下输出:
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.27 powf
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.27 logf
然后……
objdump -T /lib/libm.so.6 | grep -w logf
objdump -T /lib/libm.so.6 | grep -w powf
它给出了以下输出:
000397a0 g DF .text 00000135 GLIBC_2.27 logf
00010430 g DF .text 0000009e (GLIBC_2.0) logf
还有……
000397a0 g DF .text 00000135 GLIBC_2.27 powf
00010430 g DF .text 0000009e (GLIBC_2.0) powf
因此,有了 powf() 和 logf() 也在 GLIBC-2.0 中实现的信息,我将以下内容添加到我的项目中(在 main() 之上)并重新编译。
__asm__(".symver logf,logf@GLIBC_2.0");
__asm__(".symver powf,powf@GLIBC_2.0");
不幸的是,我的项目仍在使用 GLIBC-2.27 中的 powf 和 logf。实际上,我为 Debian 分发二进制文件非常重要,如果可以避免的话,我宁愿不必在该发行版上编译。
从历史上看,我已经成功地将这个过程用于 libc.so.6 中的符号,但不适用于 libm.so.6。我应该为 libm.so.6 做不同的事情吗?
很明显,我在这里遗漏了一些东西,因此我将感谢您提供的任何帮助。
非常感谢
阿曼达
【问题讨论】:
-
一般来说,在较新的操作系统上构建并尝试在较旧的操作系统上运行是行不通的。您应该使用旧的工具链和库设置构建机器(可能作为容器或 VM),并在那里构建。
标签: linux c++11 debian fedora glibc