c++ - musl 的 GCC 包装器与 musl 的交叉编译器有何不同?
问题描述
我正在尝试使用musl工具链编译各种程序,例如 MariaDB。也就是说,编译完成后,我不希望对 glibc 或 GNU 的链接器有任何依赖。
到目前为止,我一直在使用 musl 的 GCC 包装器musl-gcc
来编译东西。但是,对于像 MariaDB 这样的大型程序,我很难获得所有必要的库和头文件,并且符号链接或为编译添加环境变量并没有真正的帮助。
我在这个 GitHub repo 上看到提到构建一个针对 musl libc 的交叉编译器,并带有其他文档和代码。从交叉编译器的文档中:
这为您提供了一个完整的、可重定位的 musl 目标工具链,具有 C++ 支持及其自己的库路径,您可以将第三方库安装到其中。
听起来这对我有帮助,但我不确定这与 musl 的 GCC 包装器有何不同,据我所知,它只是改变了 GCC 查找库和头文件等的位置。
最终,我不确定这个交叉编译器与 GCC 包装器有多大不同,以及它是否对我有用。当我可以符号链接到现有库并使用 GCC 包装器时,为什么我需要自己的库路径来安装第三方库?交叉编译器是我应该编译的方式吗,尤其是更大的代码库?
解决方案
包装器所做的只是删除默认库并包含路径并添加替换路径。否则,它依赖于编译器认为ABI 充分匹配的观点,认为它以 glibc ( *-linux-gnu
) 为目标的 GCC 与 musl ( *-linux-musl
) 目标一起工作。
一个完整的 GCC 工具链有许多“目标库”——链接到输出程序以提供编译器提供的某些功能的库。这包括libgcc
(软件乘法或除法、软件浮点等,根据目标架构是否需要这些东西,以及对异常处理libstd++
的展开支持)、(C++ 标准库)和许多其他东西,例如libgomp
(GNU OpenMP 运行时与 ) 一起使用的实现#pragma OMP ...
。理论上,所有这些都可能取决于特定的目标 ABI,包括 libc,并可能链接到来自 libc 的符号。在实践中,大多数情况下libgcc
不会,并且只要基本类型定义和其他一些 ABI 事物匹配,就可以“安全地”与不同的 libc 重用。
对于对 libc 具有更复杂依赖关系的其他库,通常不希望针对一个 libc 的构建可以与不同的 libc 一起使用。musl libc 为使用 glibc 链接的库提供了一定程度的 ABI-compat,因此有一些希望它们无论如何都能工作,但您需要将它们复制到新的库路径。然而,GCC 的 C++ 标准库头文件似乎也对目标的 (libc) 系统头文件有一些严重依赖,并且当为 glibc 设置时似乎不适用于 musl。可能有一些方法可以使这项工作(即向包装器添加 C++ 支持),但如何做到这一点是一个悬而未决的问题。
然而,即使这可以工作,你越深入,你可能会发现你宁愿只拥有一个知道它的目标是 musl 的适当的交叉编译器工具链的原因就越多。如今,这些很容易构建。但是,如果您发现您也需要额外的第三方库,并且不想自己构建它们,那么将 Docker 映像(或其他容器)与为您提供库二进制文件的发行版一起使用可能更有意义。
推荐阅读
- c# - WPF 无法更改 DatePicker 中的时间
- typescript - 没有作为的打字稿导入
- amazon-athena - AWS Athena 发出警报
- redisearch - RediSearch FT.SEARCH 命令中的 FRAGS 参数有什么作用?
- javascript - 鼠标悬停从图像变为文本的CSS
- scala - webjars-play:如何在 Play 2.7 中使用 WebJarsUtil
- nuget - 升级包引用时如何编写更新绑定重定向的 NuGet 包?
- ruby - Ruby Webrick 服务器无法验证客户端证书
- pushbullet - 按类型过滤推送
- python - Python,如何制作异步数据生成器?