c++ - musl 的 GCC 包装器与 musl 的交叉编译器有何不同？

Question

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

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

我看到提到 building a cross-compiler targeting musl libc附加文档和代码位于 this GitHub repo 。来自交叉编译器的文档:

This gives you a full, relocatable musl-targeting toolchain, with C++ support and its own library paths you can install third-party libraries into.

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

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

Answer 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 兼容，因此希望它们无论如何都能工作，但您需要将它们复制到新的库路径。然而，GCC 的 C++ 标准库头似乎也严重依赖于目标的 (libc) 系统头，并且当设置 glibc 时似乎不适用于 musl。可能有某种方法可以完成这项工作(即向包装器添加 C++ 支持)，但具体如何做到这一点仍然是一个悬而未决的问题。

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