问题标签 [musl]

我正在尝试调试在具有 MIPS cpu 的板上远程运行的程序，使用 musl 作为其 libc。如果我在板上启动 gdbserver，设置 sysroot viaset sysroot /path/to/sysroot并从 gdb 实时连接，我会得到一个有意义的堆栈跟踪（由于 musl 在 MIPS 上缺少 CFI 指令而我不得不添加它们，这需要数小时的努力，但这是一个单独的问题)，我可以看到 gdblibc.so从 sysroot 加载符号。

另一方面，如果我让该程序崩溃并生成一个核心转储（我曾经kill -6 <pid>强制一个用于测试），gdb 将从二进制文件中加载符号，但不会加载它的任何共享库，甚至libc.so. 虽然其他共享库很好但不是必需的，但没有来自 libc.so 的调试信息，gdb 无法解析堆栈跟踪，它们看起来都像垃圾。

成功的实时 gdb 会话

（注意：在上面我用占位符替换了内部路径/文件名/等）

不成功的核心转储 gdb 会话

（注意：在上面我用占位符替换了内部路径/文件名/等）

我尝试过的事情

我尝试了几件事，包括使用set solib-search-path而不是set sysroot直接告诉gdb加载库add-symbol-file /path/to/libc.so，甚至add-symbol-file /path/to/libc.so 0xdeadbeef0xdeadbeef实际上是加载库的地址，通过readelf获得。在最后一种情况下，gdb 最终加载了符号，但显然有些地方不对劲，可能我传递的地址不正确。问题是，我不应该这样做，gdb 应该在核心转储中找到这些信息并加载库！我如何让它做到这一点，为什么它一开始不这样做呢？

muslgcc 使用libc引发以下错误

device_achat.c

在我的 rootfs 中，我需要 musl 支持。我通过添加以下内容在我的 local.conf 中添加了 musl：

构建核心图像完整命令行。我收到以下错误：

+++

make[4]: 离开目录'/home/user/yocto/poky_thud/build/tmp/work/x86_64-linux/binutils-cross-x86_64/2.31.1-r0/git/build.x86_64-linux.x86_64-poky -linux-musl/gas/po'

Makefile:1260: 目标“全递归”的配方失败

make[3]: *** [all-recursive] 错误 1

make[3]: 离开目录 '/home/user/yocto/poky_thud/build/tmp/work/x86_64-linux/binutils-cross-x86_64/2.31.1-r0/git/build.x86_64-linux.x86_64-poky -linux-musl/gas'

Makefile:808: 目标“全部”的配方失败

make[2]: *** [all] 错误 2

make[2]: 离开目录 '/home/user/yocto/poky_thud/build/tmp/work/x86_64-linux/binutils-cross-x86_64/2.31.1-r0/git/build.x86_64-linux.x86_64-poky -linux-musl/gas'

Makefile：4865：目标“全气体”的配方失败

make[1]: *** [all-gas] 错误 2

make[1]: 离开目录'/home/user/yocto/poky_thud/build/tmp/work/x86_64-linux/binutils-cross-x86_64/2.31.1-r0/git/build.x86_64-linux.x86_64-poky -linux-musl'

Makefile：849：目标“全部”的配方失败

make: *** [全部] 错误 2

错误：oe_runmake 失败

警告：从 shell 命令退出代码 1。

错误：函数失败：do_compile（日志文件位于 /home/user/yocto/poky_thud/build/tmp/work/x86_64-linux/binutils-cross-x86_64/2.31.1-r0/temp/log.do_compile.19779 )

+++

这种方法构建musl是否错误？提前谢谢

我正在使用跨Docker 容器编译一个 bindgen sys-crate。目标平台是armv5te-unknown-linux-musleabi.

我使用货物以及build.rs生成绑定。这失败并显示以下消息：

各种错误消息包括例如：

在我看来，它无法链接musl-libc. 我尝试了各种事情（例如-lc或通过-C target-feature=+crt-static，但没有帮助）。

I'm trying to build a Go executable with shared libraries. In Ubuntu, which uses GNU libc, it works. But when I try to use the same procedure on Alpine (Docker image golang:alpine, or 1.14.1-alpine3.11), which uses MUSL libc, the generated libstd.so is broken. Afterwards, if I try to compile the executable, the compilation fails.

This is the procedure:

It works as expected when I do the same procedure with the same Golang version, but other distribution that has GNU libc:

Am I missing some detail? Does Golang or Alpine have a bug?

我想找到在 Rust 构建中使用的 libc.so 文件，以便我可以使用--version. （一些 libcs​​ 通过 C 宏公开他们的版本信息，因此他们的替代方法是cc在构建脚本中使用 crate。但像 musl 这样的其他人不这样做。）

我可以弄清楚libstd-*.sorust 二进制文件或库将链接到哪个文件。当它libstd.so与主机的 libc 链接时，在其上运行ldd会显示libc.so. 但是当主机系统使用 glibc 并且目标环境是 musl 时，这不起作用（“无效的 ELF 标头”）。代替，ldd我可以使用readelf -d或objdump -p。libstd.so但是这些只显示它使用的文件的文件名，libc.so而不是它的完整路径。这libc.so不在LD_LIBRARY_PATH. （我确实知道它在我自己的系统上的位置，但我正试图以编程方式在任意系统上找到它。）

运行ldconfig -p只为我提供有关主机系统的 libc 的信息。

如果有一个 rustc 相当于 gcc 和 clang 的-print-file-name=libc.so，那就太好了，这样我就可以做类似rustc --target=$TARGET --print-file-name=libc.so.

关于如何获取此信息的其他想法？

尝试在 gitlab-ci 上设置自动内存泄漏测试时，我注意到 Valgrind 的 musl libc 存在一些问题。

.gitlab-ci.yml：

CMakeLists.txt：

结果：

在我的机器上（带有 gcc 和 glibc 的 Manjaro）它不会标记任何内存泄漏。

我可以改用 Debian，但是 Alpine 非常有用，因为它可以快速加载其 docker 映像，所以我正在寻找是否有办法在 Alpine 上使用 Valgrind。

== 更新 ==
我用一个例子创建了一个仓库：https ://gitlab.com/DPDmancul/valgrindtest

我正在尝试交叉编译一个 rust 项目，arm-linux-musleabihf并且在使用musl-cross-make. rust 项目有一个依赖项libgit2，这似乎是导致问题的依赖项。

使用：

• 最新的 rust (1.43.1 via rustup)
• arm-unknown-linux-musleabihf目标_
• 最新musl-cross-make的TARGET=arm-linux-musleabihf
• 指向TARGET_CC_linux_arm-unknown-linux-musleabihf和CARGO_TARGET_ARM_UNKNOWN_LINUX_MUSLEABIHF_LINKER在/opt/musl-cross-make/output/bin/arm-linux-musleabihf-gcc

构建时出现错误：

链接器似乎难以解析特定于 musl 的time64符号，目前尚不清楚原因。

如果：

• 我x86_64-linux-musl在 rust 和musl-cross-make
• 我musl-cross-make用MUSL_VER=1.1.24

time我还编写了一个同时使用和的小 C 程序，它stat基于交叉编译器上的 musl 1.2.0 构建，没有任何问题。

这里发生了什么？libgit2这意味着它找不到正确的__time64符号有什么特别之处？

我正在为 arm 使用 musl-targeting 交叉编译器，使用 musl-cross-make (gcc 9.2.0, musl 1.2.0) 构建。当我用 printf 编译一个简单的 hello world c 程序时，我得到标准库中符号的未定义引用：

当我将 libc.a 和 crt1.o 添加到链接器命令时，我没有收到错误：

我认为在不使用-nostartfiles、-nostdlib 或-nodefaultlibs 时不需要指定标准库和启动文件，还是我错了？

我正在尝试将我的 rust 服务器从 Heroku 移动到 Google Cloud 或 AWS。尽管我喜欢git push只指定一个 buildpack 来构建和部署到 Heroku 的简单性，但该服务对我来说并不划算。

我将 Google Cloud Run 和 AWS Elastic Beanstalk 确定为潜在的替代方案。

首先，我需要使用静态二进制文件构建 docker 映像。

因此，我添加了这个 Dockerfile：

图像构建没有错误，但如果我通过 docker run 运行它，我会收到以下错误：

standard_init_linux.go:219: exec 用户进程导致：没有这样的文件或目录

通过用 rust 替换最后一步的基础镜像，我检查了二进制文件和其他文件是否确实在镜像中。loxe-api它们是，我可以通过 ls 看到它们，但在进入 shell 时我也无法执行。

dockerd 记录这个：

这是 Cargo.toml 的依赖部分：

从容器内部进一步调查：

我还尝试从我的主机系统构建和执行。我跑了cargo run --target x86_64-unknown-linux-musl --releasewhich build the binary，但最终导致了这个错误：

错误：无法执行进程 target/x86_64-unknown-linux-musl/release/loxe-api（从未执行）

我通过以下方式检查了二进制文件的存在du -h target/x86_64-unknown-linux-musl/release/loxe-api：

对开箱即用和一些修改过的 cross、clux/muslrust 和 emk/rust-musl-builder 存储库进行了进一步的不成功尝试。

使用 x86_64-unknown-linux-musl 目标构建和运行一个新的 cargo 默认项目是可行的。我认为，libclang、brotli 或某些 argonautica 库可能会使它不起作用。

这是产生相同结果的简化 Dockerfile。