问题标签 [musl]

POSIX 声明操作系统需要提供以符合 POSIX的功能单元之一是POSIX_C_LANG_SUPPORT。基本上这是包含更多内容的整个 C 标准库。

我的问题很简单：兼容 POSIX 的操作系统的开发人员通常只需下载 C 标准库的开源版本（例如 glib 或 uClibc）并对其进行调整以适应 POSIX，或者他们从头开始实现一切？重写 C 库而不是仅仅选择一个非常知名的实现并根据我的需要进行调整是否有任何优势？

我试图制作一个基于 Alpine linux 的 docker 容器。在安装一些软件的过程中，我注意到共享库没有正确安装。经过一番调查，我发现 musl ldconfig 忽略了标准库目录。

ldconfig 脚本包含以下内容：

这是什么原因？

我在尝试使用 gdb 在 Alpine Linux 上调试 OpenJDK java 时遇到了困难——有人成功了吗？

例如，当尝试在 gdb 中调试 java 时，它会立即失败，并显示gdb java：r -version

我搜索和搜索，但找不到在 Alpine 上进行 OpenJDK 调试的任何参考或解决方案。

在其他平台（macOS Sierra、MinGW）上看到的处理相同 gdb 错误的其他线程表明，这recieved signal ?, Unknown signal可能是由各种原因导致的，包括gdb 错误、未捕获的异常、堆栈溢出和其他应用程序错误。

在 gdb 之外，java 可以正常工作，gdb 可以很好地调试一个简单的 C++ 程序。我正在运行 Alpine V3.8。

我尝试过的事情：

• 不同的 gdb 版本 ( 8.0.1-r6, 8.0.1-r3, 7.12.1-r1)。
• 不同的 OpenJDK 版本 ( 1.8.0_171, 1.7.0_181)。
• 从不同的 shell ( /bin/ash, /bin/bash) 运行，有和没有sudo.
• .gdbinit在:handle SIGSEGV nostop noprint pass和SIGPIPE, SIGHUP, SIGFPE,中禁用停止信号SIG34。
• 添加set startup-with-shell off到.gdbinit.

谢谢你的帮助！

编辑：

这是引发未知信号的完整堆栈，这会导致JVMInit失败：

与此堆栈跟踪匹配的 musl 源文件：

• 1： http: //git.musl-libc.org/cgit/musl/tree/src/thread/pthread_cancel.c
• 2： http: //git.musl-libc.org/cgit/musl/tree/src/thread/__timedwait.c
• 3、4： http: //git.musl-libc.org/cgit/musl/tree/src/thread/pthread_join.c

OpenJDK 源代码：

• 7：https ://github.com/frohoff/jdk8u-jdk/blob/master/src/solaris/bin/java_md_solinux.c

JVMInit尝试通过调用, 调用来创建本JavaMain机线程，然后它就会爆炸。ContinueInNewThreadContinueInNewThread0(JavaMain, threadStackSize, (void*)&args)

一点背景。

我的目标是在 ARM64 上使用 JRE 创建一个超薄的 docker 映像。以下是我可以影响最终图像大小的可能区域。

1. 使用 JAVA 9 及更高版本允许我利用新的 java 模块功能。
2. 为 ARM64 使用 Alpine 可提供超薄的基础映像。

到目前为止我所做的：有针对 ARM64 的 OpenJDK 9 及更高版本，使用模块功能我得到了大约 30M 的 JRE 大小，这是一个了不起的成就。

现在我正在着手迁移到 Alpine 基础映像，它需要使用 musl-libc 编译 OpenJDK。我设法用glibc重新编译了最新的OpenJDK，我的问题是用musl libc编译OpenJDK 9有多复杂，我的理解是，glibc和musl暴露了相同的接口，基本上，OpenJDK应该与musl-libc兼容。

任何应对这一挑战的方向都将不胜感激。

这是一个使用 openssl 库的简单 hello world sha1-hasher。

在安装了 libssl-dev 的 Mint/Ubuntu 上，我可以编译并链接它$CC sha.c（其中 CC 是 gcc、tcc 或 clang 之一）然后成功运行它，但这不适用于 musl 所以我抓住了 openssl源（git clone https://github.com/openssl/openssl），配置它./config --prefix=/usr/local/musl，构建它并安装它，现在musl-gcc sha.c -lcrypto works但运行LD_LIBRARY_PATH=/usr/local/musl/lib a.out让我：

是什么原因造成的，我该如何解决？

我使用 Nix 作为 Rust 程序的依赖管理器。我有以下 default.nix （简化，但工作）：

我正在尝试将所有依赖项（包括 Rust 编译器）的 libc 覆盖为 pkg.musl，但我没有这样做。如何做到这一点？

我用 gcc 和 musl-gcc 编译了这个 GTK+ 示例应用程序。两者都产生了一个二进制文件，但是 musl-gcc 产生的二进制文件不能正确执行并显示一堆错误。

注意：我安装了 musl-libc 和 libgtk3 开发版本。
注意： ldd 命令日志对于 gcc 和 musl-gcc 生成的二进制文件几乎是相同的。

GTK+ 示例应用程序：

编译命令：

musl-gcc -Wall -g -o main main.c -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 - I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr /include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr /include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -L/usr/lib /x86_64-linux-gnu -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0

musl-gcc 生成的二进制日志：

gcc 生成的二进制文件的ldd命令日志：

用于 musl-gcc 生成的二进制文件的ldd命令日志：

musl C 库只有符号版本控制的近似实现。这可能导致具有不同符号版本的符号绑定在一起，这在完整实现中不会发生。因此，希望使用 musl 构建的项目最好完全避免符号版本控制。（不支持符号版本控制本身对于工具链来说不一定是一个糟糕的选择；这完全取决于目标受众。）

然而，Alpine Linux 工具链编译 binutils 时具有完整的符号版本支持：GAS 支持.symver指令，链接编辑器处理版本脚本并分配符号版本（就像在 GNU/Linux 上一样）。一个简单的编译器/汇编器或链接器检查表明支持符号版本控制。结果，Alpine Linux 包含在发行版中的一些共享对象实际上使用了符号版本控制，尽管 musl 动态加载器会忽略这些数据。（数据只会使二进制文件膨胀。）

在某些情况下，软件无法运行（在构建良好之后），因为它以 musl 动态链接器不支持的方式使用兼容性符号（没有默认版本的符号）。这是一个不起作用的小例子：

执行失败，出现Error relocating ./symver.so: compat_function: symbol not found. 它在没有.symver指令的情况下成功运行。

这种 binutils 支持符号版本控制的组合与不支持它的动态链接器的组合如何在实践中工作？项目是否应该检查 *-musl目标三元组并禁用符号版本控制？

动态链接器支持的运行时检查可以完成这项工作，但它会破坏交叉编译。是否应该通过禁用 binutils 中的符号版本控制支持在 Alpine Linux 本身中解决此问题？

我目前正在寻找一种方法来制作我刚刚编译的二进制文件，这是一个适用于大多数 linux 环境的可移植二进制文件。我正在考虑 Ermine，但它不是免费的（现在正在寻找免费的解决方案）并且也尝试使用 Statifier 但也没有用。这是我试图制作静态和可移植的二进制文件的详细信息：

如果有人能告诉我如何准确地将所有库链接到二进制文件，以便它可以在所有或几乎所有 linux env（2.6.18 内核到最新版本）上轻松运行，将不胜感激。

谢谢

这是一个好奇的问题：为什么？

为什么完全相同的代码会有不同的行为？

我经常遇到这样的问题，即我可以在一个发行版中编译某些东西，但不能在另一个发行版中编译。所以今天我又遇到了一个问题，当我以与 ArchLinux 相同的方式构建 PostgreSQL 的 pg_dump 时，它可以工作，但是当我在 Alpine 上这样做时，它会失败并出现以下错误：

这是 Alpine 的 Dockerfile：

这是 ArchLinux 的 Dockerfile：

我什至不知道在哪里看。这可能是musl版本的不同吗？另一个编译工具？我真的不想要解决方案，我想了解原因。