Linux二进制文件通常动态链接到核心系统库(libc)。这样可以使二进制文件的内存占用空间很小,但是依赖于最新库的二进制文件将无法在较旧的系统上运行。相反,链接到较早的库的二进制文件将在最新的系统上愉快地运行。
因此,为了确保我们的应用程序在分发期间具有良好的覆盖范围,我们需要找出我们可以支持的最旧的libc并将其链接到该二进制文件。
我们应该如何确定可以链接到的最旧版本的libc?
找出可执行文件中的哪些符号正在创建对不需要版本的glibc的依赖。
$ objdump -p myprog
...
Version References:
required from libc.so.6:
0x09691972 0x00 05 GLIBC_2.3
0x09691a75 0x00 03 GLIBC_2.2.5
$ objdump -T myprog | fgrep GLIBC_2.3
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.3 realpath
查看附属库中的内容,以查看是否可以链接较旧版本的任何符号:
$ objdump -T /lib/libc.so.6 | grep -w realpath
0000000000105d90 g DF .text 0000000000000021 (GLIBC_2.2.5) realpath
000000000003e7b0 g DF .text 00000000000004bf GLIBC_2.3 realpath
我们很幸运!
从GLIBC_2.2.5
您的代码中请求版本:
#include <limits.h>
#include <stdlib.h>
__asm__(".symver realpath,realpath@GLIBC_2.2.5");
int main () {
realpath ("foo", "bar");
}
观察到不再需要GLIBC_2.3:
$ objdump -p myprog
...
Version References:
required from libc.so.6:
0x09691a75 0x00 02 GLIBC_2.2.5
$ objdump -T myprog | grep realpath
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 realpath
有关更多信息,请参见http://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/?p=103。
问题内容: 安装新的构建机器后,我发现它带有标准C ++库的6.0.10 但是,我们的许多目标计算机仍使用旧版本的libstdc ++,例如: 显然,在最后两个0.0.1中,ABI发生了变化,因为尝试运行程序会导致 我尝试明确安装旧版本的gcc,但没有帮助。升级目标计算机是我无法控制的,因此不是一种选择。使我的构建在具有较旧libstdc ++的计算机上工作的最佳方法是什么? 我在apt-cach
几天前,我在play store上发布了Flatter android应用程序,现在我想在play store中更新该应用程序,因此对代码进行了更改,但现在我很困惑,我是否必须使用与第一次发布应用程序时相同的过程来生成新密钥(生成密钥,然后运行Flatter build应用程序包),还是必须遵循其他程序。请帮忙,万分感谢。
如果您感觉下载旧版本的应用程序时存在困难,或者找不到需要的版本,请使用下面表格中的下载链接。 注意:需要获取有关下载应用程序最新版本的帮助?请借助这些实用的指导说明,了解如何下载并安装 Creative Cloud 应用程序。 2017 年版本的应用程序 产品 Windows Mac OS Illustrator CC (2017) Windows(32 位)| Windows(64 位) Mac
我在play store中有一个版本为6.0.3的android应用程序,我们有一个新版本,即6.0.4。如果安装的版本较旧,我需要一个代码以弹出通知提示用户进行更新。如何从play store获取版本并进行比较。
我试图获得基于gradle的android项目的覆盖面。 所以我为我的应用程序添加版本。gradle 和 内部调试。 这工作正常。我可以获取使用或的报告。 问题是调试版本通常被开发人员用来运行和测试应用程序。因此,在构建中启用代码覆盖可能会降低构建的速度,这种用法可能不需要。 所以我想我会添加新的配置 不幸的是,没有和不运行覆盖类型。 当我使用dex2jar反编译apk并使用jd-gui查看内部时
问题内容: 在x86_64 linux上使用gcc和ld我需要链接到库的新版本(glibc 2.14),但是可执行文件需要在具有旧版本(2.5)的系统上运行。由于唯一不兼容的符号是memcpy(需要memcpy@GLIBC_2.2.5,但提供memcpy@GLIBC_2.14的库),我想告诉链接器,它应该使用我指定的旧版本,而不是使用memcpy的默认版本。 。 我发现这样做很尴尬:只需在链接器命