如何解决如何检查二进制文件是否“可运行”
在我的 CI 设置中,我将我的 C 代码编译成许多不同的架构(x86_64-linux-gnu,i386-linux-gnu
、aarch64-linux-gnu
、arm-linux-gnueabihf
、x86_64-apple-darwin
、{{1 }}、i386-apple-darwin
、i686-w64-mingw32
、...)。
我可以简单地通过“启用它们”来添加新的架构(至少对于 *-linux-gnu)。
相同的 CI 配置用于许多项目(由不同的开发人员),并努力实现几乎“零配置”(例如:“在您的项目中删除此 CI 配置并忘记它,其余的会照顾你”)。
一些目标是本地编译的,其他目标是交叉编译的。一些交叉编译的架构可以在构建机器上运行(例如我可以在 x86_64-w64-mingw32
上运行 i386-apple-darwin
二进制文件),其他的不兼容(例如我不能在 x86_64-apple-darwin
上运行 aarch64-linux-gnu binaries
}}).
到目前为止一切都很好。
但是,我也想在 CI 期间运行单元测试 - 但前提是单元测试实际上可以在构建机器上执行。 我对获得大量失败的测试完全不感兴趣,因为我正在交叉构建二进制文件。
让事情稍微复杂一点,我正在构建的不是自包含的可执行文件,而是由主机应用程序 dlopen() ed(或目标平台上的任何等效项)的插件。主机应用程序通常启动速度很慢,所以如果它无论如何都不能使用插件,我想避免运行它。 构建插件也意味着我不能只是尝试运行它们。
我正在使用 GNU 工具链(make、gcc),或者至少是兼容的东西(比如 clang))。
在我第一次尝试检查我是否正在交叉编译时,我将构建过程的目标架构(由 x86_64-linux-gnu builder
返回)与 GNU make 的架构(当使用 ${CC} -dumpmachine
标志调用时,GNU make 将输出用于构建 make 自身的架构三元组。
以下类似的东西效果出奇地好,至少对于 -v
目标是这样:
*-linux-gnu
但是,它在 Windows/MinGW 上根本不起作用(在进行本机构建时,gcc 以 if make --version | egrep ${TARGETARCH:-$(${CC:-cc} -dumpmachine) >/dev/null; then
echo "native compilation"
else
echo "cross compiling"
fi
为目标,但是 make 是为 { 构建的{1}};更糟糕的是,在构建 32 位二进制文件时,当然可以完全运行)或 macOS(gcc 表示 x86_64-w64-mingw32
,make 表示 x86_64-pc-msys
(不要问我为什么))。
这变得更加严重了,因为在我写这篇文章并做一些检查时,我注意到即使在 Linux 上我也会得到类似 x86_64-apple-darwin18.0.0
与 i386-apple-darwin11.3.0
;这些差异还没有出现在我的 CI 构建者身上,但我相信这只是时间问题)。
因此,我正在寻找更强大的解决方案来检测我的构建主机是否能够运行生成的二进制文件,如果不能,则跳过单元测试。
解决方法
根据我对您的要求的了解(如果我没有抓住要点,我将删除此答案),您可以分三步进行:
检测您的构建过程,以便它生成您正在使用的所有(gcc 'dumpmachine',make 'built for')对的确切列表。
仅将允许执行程序的对保留在列表中。
使用您收集的信息,从 bash 确定您是否可以执行二进制文件或不给定反映您系统的对:
#!/bin/bash
# Credits (some borrowed code):
# https://stackoverflow.com/questions/12317483/array-of-arrays-in-bash/35728122
# bash 4 could use associative arrays,but darwin probably only has bash3 (and zsh)
# pairs of gcc -dumpmachine
# ----- collected/formatted/filtered information begins -----
entries=(
'x86_64-w64-mingw32 x86_64-pc-msys'
'x86_64-pc-linux-gnu x86_64-linux-gnu'
'x86_64-apple-darwin18.0.0 i386-apple-darwin11.3.0'
)
# ----- collected/formatted/filtered information ends -----
is_executable()
{
local gcc
local make
local found=0
if [ $# -ne 2 ]
then
echo "is_executable() requires two parameters - terminating."
exit 1
fi
for page in "${entries[@]}"
do
read -r -a arr <<< "${page}"
gcc="${arr[0]}"
make="${arr[1]}"
if [ "$1" == "${gcc}" ] && [ "$2" == "${make}" ]
then
found=1
break;
fi
done
return ${found}
}
# main
MAKE_BUILT_FOR=$( make --version | sed -n 's/Built for //p')
GCC_DUMPMACHINE=$(gcc -dumpmachine)
# pass
is_executable ${MAKE_BUILT_FOR} ${GCC_DUMPMACHINE}
echo $?
# pass
is_executable x86_64-w64-mingw32 x86_64-pc-msys
echo $?
# fail
is_executable arm-linux-gnueabihf x86_64-pc-msys
echo $?
作为额外的预防措施,您可能应该验证您正在使用的 gcc 'dumpmachine' 和 make 'built for' 在 gcc 列表中,您正在使用,并记录如果不是这种情况,则会显示错误消息和/或退出。
,也许包括一个额外的单元测试,可以直接运行,只是一个“hello world”或 return EXIT_SUCCESS;
,如果它失败了,跳过该架构的所有其他插件测试?
有趣的事实:至少在 Linux 上,共享库(ELF 共享对象)可以有一个入口点并且是可执行的。 (这就是 PIE 可执行文件的制作方式;以前愚蠢的编译器/链接器技巧现在是默认设置。)IDK 如果将 main
烘焙到您现有的插件测试之一会有用。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。