musl 的 GCC 包装器与 musl 的交叉编译器有何不同？答案

【问题标题】：How does musl's GCC wrapper differ from musl's cross-compiler?musl 的 GCC 包装器与 musl 的交叉编译器有何不同？
【发布时间】：2020-10-06 17:12:19
【问题描述】：

我正在尝试使用musl 工具链编译各种程序，例如 MariaDB。也就是说，编译完成后，我不希望对 glibc 或 GNU 的链接器有任何依赖。

到目前为止，我一直在使用 musl 的 GCC 包装器 musl-gcc 来编译东西。但是，对于像 MariaDB 这样的大型程序，我很难获得所有必要的库和头文件以及符号链接或为编译添加环境变量doesn't really help。

我在this GitHub repo 看到提到了building a cross-compiler targeting musl libc 以及其他文档和代码。来自交叉编译器的文档：

这为您提供了一个完整的、可重定位的 musl 定位工具链，具有 C++ 支持及其自己的库路径，您可以将第三方库安装到其中。

听起来这对我有帮助，但我不确定这与 musl 的 GCC 包装器有何不同，据我了解，后者只是改变了 GCC 查找库和标头等的位置。

最终，我不确定这个交叉编译器与 GCC 包装器有多大不同，以及它是否对我有用。当我可以符号链接到现有库并使用 GCC 包装器时，为什么我需要自己的库路径来安装第三方库？交叉编译器是我应该编译东西的方式吗，尤其是更大的代码库？

【问题讨论】：

现在只需在docker run alpine编译
@KamilCuk 是的，这是一个选项。但是，我正在尝试运行一些 musl 与 glibc 编译程序的基准测试，并且所有 glibc 编译都是在 Debian 上完成的。所以为了保持一致性，我想把东西放在 Debian 上。
@peachykeen -- 但是您使用什么 Linux 发行版是否重要，因为您明确删除了平台级依赖项？如果你在 Alpine VM 上为 MUSL 构建，在 Debian VM 上为 glibc 构建，并且两个 VM 在同一主机上运行，那不是提供了一个公平的竞争环境吗？

标签： c++ c gcc glibc musl

【解决方案1】：

包装器所做的只是删除默认库并包含路径并添加替换路径。否则，它依赖于编译器对 ABI 的充分匹配，认为它以 glibc (*-linux-gnu) 为目标的 GCC 与 musl (*-linux-musl) 目标一起工作。

完整的 GCC 工具链有许多“目标库”——链接到输出程序以提供编译器提供的某些功能的库。这包括libgcc（软件乘法或除法，软件浮点等，根据目标架构是否需要这些东西，以及对异常处理的展开支持），libstd++（C++ 标准库）和其他一些诸如libgomp（与#pragma OMP ... 一起使用的GNU OpenMP 运行时实现）之类的东西。理论上，所有这些都可能依赖于特定目标 ABI，包括 libc，并可能链接到来自 libc 的符号。在实践中，大多数情况下libgcc 不会，只要基本类型定义和其他一些 ABI 匹配，就可以“安全地”与不同的 libc 重用。

对于对 libc 具有更复杂依赖关系的其他库，通常不希望针对一个 libc 的构建可以与不同的 libc 一起使用。 musl libc 为使用 glibc 链接的库提供了一定程度的 ABI-compat，因此有一些希望它们无论如何都能工作，但您需要将它们复制到新的库路径。然而，GCC 的 C++ 标准库头文件似乎也对目标的 (libc) 系统头文件有一些严重依赖，并且当 glibc 的设置似乎不适用于 musl。可能有一些方法可以使这项工作（即向包装器添加 C++ 支持），但如何做到这一点是一个悬而未决的问题。

即使这可以工作，但是，你越深入，你可能会发现你宁愿拥有一个知道的适当的交叉编译器工具链的理由就越多它的目标是musl。如今，这些很容易构建。但是，如果您发现您也需要额外的第三方库，并且不想自己构建它们，那么将 Docker 映像（或其他容器）与为您提供库二进制文件的发行版一起使用可能更有意义。

【讨论】：