问题标签 [musl]

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

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

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

从逻辑上讲我想做

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

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

我正在尝试使用musl-gcc构建FIO（由于 glibc 的许可问题，我们需要使用 musl）。我正在尝试使用 musl 提供的头文件而不是 glibc，但到目前为止编译 FIO 并不成功。我首先使用以下选项运行配置：

然后运行make：

我不明白为什么我会收到此文件的错误 - 当我尝试为 x86_64 构建（在配置选项中使用它）时，它看起来是 crc/crc32c-arm64.c。它会查找 linux/*.h，但 /usr/local/musl/include 中没有“linux”文件夹。我通过包含 /usr/include 来再次运行它（它确实有 linux/*.h），如下所示：

但是现在当我运行 make 时出现不同的错误：

使用的版本：musl-1.1.23、fio-3.15、gcc-4.4.6

如果我只使用 glibc，它可以在不使用 musl 的情况下构建良好。如何使用 musl 而不是 glibc 成功构建 FIO？这可能吗？

我正在尝试在 Alpine Linux 上使用 g++/gcc 编译 OpenCascade (OCE)。它在 Ubuntu 上构建良好，但同一项目在 Apline 上失败并出现错误：

我真的不明白为什么这是 Alpine 的错误，而不是 Ubuntu，有没有人知道为什么或遇到过类似的问题？

我正在尝试在 Alpine 上运行我的 rust 应用程序，但在使用 musl 作为目标或使用 glibc 的兼容层时遇到问题。当我尝试使用时，libc6-compat我遇到了这个问题：

这是一个错误还是兼容层根本不支持这个符号？

当我尝试以 musl 为目标时，我遇到了不同的问题。我无法直接在 musl 上编译我的应用程序，因为 rust 编译器的某些功能不受支持。我所做的是编译一个以 musl 为目标的 debian 映像并将我的二进制文件移动到我的 alpine 映像。看起来即使针对 musl，链接器在构建时仍然使用一些 glibc 变体，我对 C 的一点经验并不能帮助我确定这是否会成为问题。我的应用程序依赖于我通过 apk 安装的 glib2当它启动时，它会失败并显示以下内容：

我试图直接在我的 alpine 容器中编译一个 C 示例并且它在那里工作，所以这让我相信我的 glibc 容器中的交叉编译/链接存在一些问题。关于如何解决这个问题的任何想法？ 

注意：我可以只使用 glibc 容器，但我认识的容器都没有最小的包管理器。debian 变体安装了太多我的依赖项不需要的过时软件（我不明白为什么它们会根据包管理器的要求插入可选的依赖项），使图像大于 1GB，而我的 alpine 版本是 100MB。RPM 变体的模式相同。我可以使用大于 100MB 的图像，但不是 1GB。

我编写了一个应用程序，它使用了几个三角函数（sin、tan、cos、...）。我的目标是研究这些函数在 GNU C 库、MUSL 和 Newlib 中的不同实现。

为此，glibc我musl刚刚使用 Buildroot 构建了一个 Linux GCC 工具链，然后我使用适当的编译器编译了我的应用程序，然后使用 QEMU（用户模式）运行它。这很简单。

现在我想将应用结果与 Newlib 版本进行比较。

在我的具体情况下，我正在为 RISC-VRV64GC架构和lp64dABI 进行编译。据我了解，使用 Newlib 库意味着使用编译器进行riscvv64-unknown-elf-gcc编译。传统上，Spike ISS 模拟器可用于使用proxy-kernel轻量级操作系统运行应用程序。有没有办法在 QEMU 中使用它？还是我应该构建一个完全裸机的应用程序？

我试图弄清楚为什么 GCC 生成的二进制文件如此之大。

考虑这个空程序：

现在我使用GCC 9.2.1 20190827 (Red Hat 9.2.1-1)和glibc 2.29构建它，没有任何附加参数：

gcc -o test test.c

生成的二进制文件为 21984 字节 (~22 KB)。查看生成的文件xxd，在多个地方有很长的空字节：

所以生成的二进制文件大约有 10 KB，或几乎一半，其中没有任何内容。

用 看size -A，大小更像是人们对程序的期望，除了返回退出代码之外什么都不做：

当使用GCC 9.2.0和musl 1.1.23为 PowerPC 进行交叉编译时，情况更糟。二进制文件的大小增长到 67872 字节（~67 KB），用 看xxd，有 64074 字节的连续运行，只有零。

不过，size -A报告此版本的尺寸更小：

我还尝试使用旧版本的 GCC 编译程序，我碰巧有它：GCC 4.7.2 with uClibc 1.0.12。使用这种组合，生成的二进制文件只有 4769 字节 (~4 KB)，并且其中没有明显的空字节运行。

为了确保这不仅仅发生在什么都不做的小程序上，我查看了一些我用GCC 9.2.0和musl 1.1.23交叉编译的真实程序。例如，使用编译-Os和剥离的 tcpdump 二进制文件包含一个 32628 字节长的空字节连续运行。那么，为什么零试图消耗我所有的磁盘空间呢？

.libs/pam_rhosts.o: In function pam_sm_authenticate: pam_rhosts.c:(.text+0x1e4): undefined reference to ruserok'

在为 arm64 编译 Linux-PAM-1.1.8 时。我得到这个错误。

ruserok 在宏检查下定义

但我不是用 Uclibc 而是用 musl

我现在能做什么？

与 libc.so 链接的程序通过 plt 调用 libc 函数，比如说 setenv()。在 setenv() 内部，它调用 malloc()，至少根据 musl libc。

setenv()->malloc() 调用是否总是必须通过 plt 并得到？RIP 相对寻址不会更好吗，因为即使启用了 ASLR，您也只是移动整个 VMA？

我有一个通常使用 GLIBC 构建和执行的应用程序。我的一位用户正试图在使用 MUSL C 库（声称与 GLIBC 兼容）构建的平台上使用它。

这样做时，他们会遇到 MUSL 实现的ldd符号解析失败__strftime_l，但实际上并未将其导出为外部可见符号。

有没有办法阻止应用程序构建反对 GLIBC 将函数strftime_l()转换为__前缀版本，例如__strftime_l()在运行时解析的符号表中？

我正在使用 musl：https ://www.musl-libc.org

如果我浏览存储库，我可以看到有一堆与 crypt 相关的源文件（包括 crypt_sha256.c）。

问题是它们没有头文件。我应该如何使用它们？

这些是我系统上库中的符号：

我也无法从谷歌找到任何代码示例如何使用 musl 的 SHA-256 功能。

谢谢！