标签: musl

我有一个使用CMake构建的C / C ++项目。在尝试编译静态二进制文件时，我GLIBC在计算机和目标计算机上遇到了不同版本的问题。在关于SO的另一个问题中，对类似问题的公认答案是使用libc的替代实现，例如musl或uClibc。（请参阅此处）

我找不到有关如何指向cmake使用此类替代libc的任何信息。FindMusl.cmake文件既没有寄出，也无法在互联网上找到。简单使用CC=/usr/bin/musl-gcc是行不通的。

如何将我的cmake项目与此类替代libc实现静态链接，使其独立于GLIBC？

我有一个依赖于Hyper和Diesel的项目,因此,在本机库OpenSSL和libpq上.该项目建立在每晚Rust上,因为它使用编译器插件.

我目前的尝试是建立在Docker容器上.我有MUSL libc和库make'd并安装了前缀/usr/local/musl.我cargo使用以下命令运行:(不确定某些选项是否冗余,我不太熟悉编译器链,甚至不确定它们是否最终到链接器,但我必须尝试,对.)

LDFLAGS="-static -L/usr/local/musl/lib" \
LD_LIBRARY_PATH=/usr/local/musl/lib:$LD_LIBRARY_PATH \
CFLAGS="-I/usr/local/musl/include" \
PKG_CONFIG_PATH=/usr/local/musl/lib/pkgconfig \
cargo build --release --target=x86_64-unknown-linux-musl

当我ldd得到的文件,它揭示了这个:

$ ldd server
linux-vdso.so.1 (0x00007fffb878e000)
libpq.so.5 => /usr/local/musl/lib/libpq.so.5 (0x00007f4d730e7000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f4d72e82000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f4d72a85000)
libc.so => /usr/local/musl/lib/libc.so (0x00007f4d727f6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4d725f2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4d72246000)
/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x000055e2124a2000)

有所有动态链接的东西,有些甚至与"x86_64-linux-gnu"链!什么地方出了错？

我可以毫无问题地制作静态链接,简单的纯Rust项目.ldd说它们是静态链接的,它们运行没有问题,不像我遇到问题的可执行文件.

当我使用--verbose与货物,我得到了下面rustc的命令,即实际编制的可执行文件:http://pastebin.com/ywv0zNBK(哎呀,这人有一个自定义的outdir和-Z print-link-args,由我添加)添加print-link-args标志,我得到了下面的链接器命令:http://pastebin.com/Aw43qd7h

我如何得到 …

musl C 库只有符号版本控制的近似实现。这可能导致具有不同符号版本的符号绑定在一起，这在完整实现中不会发生。因此，希望使用 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 …

musl 团队声称不需要检测 musl libc 的方法，因为他们只实现标准功能并且没有需要检测的怪癖。

直到今天，这种说法很可能是正确的，但它不再是正确的。正常功能检测不起作用，因为该功能存在但已损坏，我宁愿不对其进行探测，因为我不想在编译时要求 root 并禁止交叉编译。该错误已通过最小化示例代码报告，维护人员根本不想修复它，也不会接受我的补丁。

我不会惩罚所有其他 libc，因为 musl 有一个损坏的功能。

从逻辑上讲我想做

#if MUSL || APPLE
    pid = fork();
#else
    pid = vfork();
#endif

我已经有了，#if APPLE因为 Mac OSX 有一个不值得信赖的vfork().

说我vfork()不好是没有意义的。自 2008 年以来，情况发生了变化vfork()，无论涉及的复杂性如何，只要有可能，这都是更好的选择。一些来源：https : //gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234

我尝试使用以下命令在ARM Cortex A7上为OpenWRT编译一个简单的.NET Core hello world 应用程序：linux-musl-arm

dotnet publish --configuration Release --runtime linux-musl-arm --self-contained

root@Routeur:~/RutxApp# ./RutxApp
Error relocating ./RutxApp: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev: symbol not found
Error relocating ./RutxApp: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj: symbol not found
Error relocating ./RutxApp: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_assignERKS4_: symbol not found
Error relocating ./RutxApp: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj: symbol not found
Error relocating ./RutxApp: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_mutateEjjPKcj: symbol not found
Error relocating ./RutxApp: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_appendEPKcj: symbol not found
Error relocating ./RutxApp: _ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5rfindEPKcjj: symbol not found
Error relocating ./RutxApp: _ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5rfindEcj: symbol not found
Error relocating …