musl C库只有an approximative implementation of symbol versioning。这可能导致具有不同符号版本的符号绑定在一起,这在完整实现中不会发生。因此,期望完全使用musl构建的项目最好完全避免使用符号版本控制。 (不支持符号版本控制本身不一定对工具链来说是一个错误的选择;这完全取决于目标受众。)
但是,Alpine Linux工具链编译了具有完整符号版本支持的binutils:GAS支持.symver
指令,链接编辑器处理版本脚本并分配符号版本(就像在GNU / Linux上一样)。简单的编译器/汇编器或链接器检查表明,符号版本控制 受支持。结果,Alpine Linux包含在发行版中的某些共享库实际上使用了符号版本控制,尽管musl动态加载程序将忽略此数据。 (数据只会使二进制文件膨胀。)
在某些情况下,软件无法运行(在正常构建后),因为它以musl动态链接器不支持的方式使用了兼容性符号(没有默认版本的符号)。这是一个无效的小例子:
cat > symver.c <<EOF
void
compat_function (void)
{
}
__asm__ (".symver compat_function,compat_function@SYMVER");
void
call_compat_function (void)
{
return compat_function ();
}
EOF
echo "SYMVER { };" > symver.map
cat > main.c <<EOF
extern void call_compat_function (void);
int
main (void)
{
call_compat_function ();
}
EOF
gcc -fpic -shared -o symver.so -Wl,--version-script=symver.map symver.c
gcc -Wl,--rpath=. -o main main.c symver.so
./main
执行失败,并显示Error relocating ./symver.so: compat_function: symbol not found
。它在没有.symver
指令的情况下成功运行。
binutils对符号版本控制的支持与不支持它的动态链接器如何结合起来在实际中如何工作?项目是否应检查*-musl
目标三元组并禁用符号版本控制?
运行时检查动态链接程序支持将完成此任务,但会中断交叉编译。是否应该通过在binutils中禁用符号版本支持在Alpine Linux本身中解决此问题?