musl的GCC包装器和musl的交叉编译器有什么不同？

Question

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

到目前为止，我一直在使用musl的GCC包装器，musl-gcc来编译东西。但是，对于MariaDB这样的大型程序，我很难获得编译不会有什么帮助所需的所有库和头以及符号链接或添加环境变量。

我看到在这个GitHub回购上提到了附加文档和代码的这个GitHub回购。来自交叉编译器的文档：

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

这听起来可能对我有帮助，但我不知道这与musl的GCC包装有什么不同，据我所知，它只是改变GCC查找库和标头等的位置。

最终，我不确定这个交叉编译器与GCC包装到底有多大的不同，以及它在我的情况下是否有用。为什么我需要自己的库路径来安装第三方库，而我只需要将链接到现有的库并使用GCC包装器呢？交叉编译器是否是我应该编译的东西，特别是更大的代码库？

Answer 1

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

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

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

即使这是可行的，但是，你走得越深，你就会发现你更愿意拥有一个正确的交叉编译器工具链，知道它的目标是musl。现在这些建筑已经很容易建造了。但是，如果您发现自己也需要附加的第三方库，并且不想自己构建它们，那么只使用Docker映像(或其他容器)和一个为您提供库二进制文件的发行版可能更有意义。