问题标签 [musl]

我有一个使用 CMake 构建的 C/C++ 项目。在尝试编译静态二进制文件时，我在GLIBC计算机和目标计算机上遇到了不同版本的问题。在关于 SO 的另一个问题中，对类似问题的公认答案是使用 libc 的替代实现，例如muslor uClibc。（见这里）

我找不到任何关于如何指出cmake使用这种替代 libc 的信息。既没有提供FindMusl.cmake文件，也无法在 Internet 上找到文件。简单地使用CC=/usr/bin/musl-gcc是行不通的。

如何将我的 cmake 项目与此类替代 libc 实现静态链接，使其独立于 GLIBC？

我有一个 C99 共享库，我想将它链接到几个静态库中（通过--whole-archive）。注意：所有静态库都是用-fPIC

我还想构建一个通用的 linux 二进制文件，因此决定使用 musl。当我尝试libc.a从 musl 链接静态时，出现以下错误：

我的 musl 构建看起来像：

第一个问题：使用单个 C++11 二进制文件支持各种“标准”Linux 平台的最佳方式是什么？这个二进制文件使用了一些第三方库，包括 boost、zlib、xml2、openssl（所有这些我都可以静态构建）。

二进制文件必须在 x86_64 的各种 Linux 平台上运行：Ubuntu 16.04 和 14.04、Centos 7.2 和 Debian。很快它就必须在 Beagle Bone Black 上的 Darwin x86_64 和 Ubuntu 16.04 上运行。

编译器、libstdc++ 和 libc 运行时的默认版本在这些平台上差别很大。我在 Ubuntu 14.04 上使用这些编译器选项（注意不使用“-static”开关）升级了（工具链 r-test）g++ 5.3 编译器，并在 Linux 上取得了一些成功：

但是，这需要在主机上安装升级后的 5.3 编译器（默认为 4.9 IIRC）和目标平台上的一些运行时库，这不是首选并且存在 libc.so 问题的风险。如果应该确定这种解决方案是最好的，那么我宁愿在 16.04 上使用最新的 g++ 或带有开关的 clang 构建二进制文件，这样二进制文件就可以在旧平台上运行，而对默认值的更改最少。是的，我知道我可能在求月亮：）

第二个问题：不是一个二进制文件，而是一个编译器和 libc，适用于所有平台，包括 Darwin 和 Windows？

我也在考虑尝试使用 musl 创建一个“行为更一致的二进制文件”。我可以考虑使用 clang 而不是 g++。

任何有经验/建议的人？我非常希望避免为每个平台维护单独的编译和第三方库和编译器的组合以及设置和升级（特别是对于 Linux 目标，但对于不同的操作系统来说非常典型）。

使用相同版本的相同编译器和可能相同版本的 libc 是最好的，但可能是不可能的：clang 与 musl？

谢谢

我正在尝试在运行 OS X 10.11.5 的机器上构建musl-libc。不幸的是，我在运行时收到以下错误make：

我正在使用 Clang 7.3.0 (703-0-31)，并且我正在使用从 musl repo 中提取的源代码git://git.musl-libc.org/musl。

我有一个项目依赖于 Hyper 和 Diesel，因此依赖于本地库 OpenSSL 和 libpq。该项目基于 nightly Rust 构建，因为它使用编译器插件。

我目前的尝试是在 Docker 容器上构建。我有 MUSL libc 和库make，并安装了前缀/usr/local/musl。我cargo使用以下命令运行：（不确定某些选项是否多余，我对编译器链不太精通，甚至不确定它们是否最终到达链接器，但我必须尝试，对.)

当我ldd得到结果文件时，它揭示了这一点：

有所有动态链接的东西，有些甚至是“x86_64-linux-gnu”链！什么地方出了错？

我可以毫无问题地制作静态链接的简单纯 Rust 项目。ldd说它们是静态链接的，并且它们运行没有问题，与我遇到问题的可执行文件不同。

当我--verbose与 Cargo 一起使用时，我得到了以下rustc实际构建可执行文件的命令：http: //pastebin.com/ywv0zNBK（哎呀，那个有一个自定义outdir和-Z print-link-args，由我添加）添加print-link-args标志，我得到以下链接器命令： http: //pastebin.com/Aw43qd7h

我如何获得cargo或rustc相信我想要一个静态二进制文件？

我想将此作为错误发布，但我什至不知道应该向谁报告。这里是。

我已经在标准的 Alpine 3.5 上安装了 Odoo 9.0，同时使用了打包的 Python 2.7.13，我也尝试过使用从源代码编译的相同版本的 python，但结果是相同的：

当我从 Odoo 应用程序中的任何视图导航到会计仪表板 python 段错误时。奇怪的是，如果我复制会计仪表板的 URL 并粘贴到导航栏中——这样会强制加载整个页面——一切正常。我在 python 解释器上尝试了 gdb，看看会发生什么。该错误似乎大部分是一致的，但不幸的是我得到的信息没有那么有用：

在极少数情况下错误是不同的，我设法在调试器中捕获它一次：

这种情况下的堆栈跟踪很长，这只是一个片段。只是为了解决这个问题，我确实尝试了 grsec 内核和香草内核，结果相同。

我对 python 很陌生，所以关于如何进一步调试或解决这个问题的任何想法将不胜感激。

我在 amd64 Debian 机器上，正在尝试构建 x86_64-unknown-linux-musl 可执行文件。我的 Cargo.toml 中有这个：

当我跑步时，cargo build --target=x86_64-unknown-linux-musl我得到了这个：

当我重新运行它时：

当我本地构建时，一切都很好，即cargo build --target=x86_64-unknown-linux-gnu.

环顾四周，我了解了一个环境变量 PKG_CONFIG_ALLOW_CROSS：

在这样做的过程中，我还发现我缺少名为libcurl4-openssl-dev的 Debian 软件包。

运行ldd target/target/x86_64-unknown-linux-musl/debug/foo 表明可执行文件是动态链接的，然后进一步搜索，我了解到另一个环境变量PKG_CONFIG_ALL_STATIC：

这揭示了一大堆缺失的 deps，所有这些（幸运的是）都具有 Debian 依赖项。但是安装所有这些并没有帮助，因为最后，我仍然坐在一个非静态链接的可执行文件中。

我使用 gcc-6.3.0、musl-1.1.16 和 binutils-2.27 从头开始​​为 MIPS 24kc (dragino) 目标平台构建了一个自定义工具链。该工具链功能齐全。

但是，my-custom 工具链的大小是等效 OpenWRT 生成的工具链大小的五倍（557M 对 113M）。OpenWRT (mips-openwrt-linux-musl-*) 生成的工具链二进制文件与 libstdc++ 和 libgcc_s 库动态链接。但是，我的工具链二进制文件与这些库静态链接：

cc1 和 cc1plus 也会出现同样的链接问题。这两个二进制文件的大小很大（cc1 为 124MB，cc1plus 为 134MB）。

我的问题是：设置跨工具链生成以获得与 OpenWRT 生成的工具链一样小的跨平台工具链的正确方法是什么？

您可以在下面找到我正在执行的构建我的自定义工具链以供参考的步骤：

下载来源：

设置构建环境：

构建本机 binutils：

构建原生 gcc：

构建跨binutils：

安装内核头文件：

构建跨 gcc（阶段 1）

建立交叉肌肉

构建跨 gcc（第 2 阶段）

提前感谢您的所有评论！

我正在尝试用 x11 编译一个程序并将 musl 用于 c 库。我的系统上仍然有 glibc。Musl 位于/usr/local/musl/includeThe glib headers are still in/usr/include

当我与

我明白了fatal error: X11/Xlib.h: no such file or directory

如果我尝试

它包含 glib 标头而不是 musl 标头，并引发一堆错误。

如果我尝试

它仍然在 /usr/include 中包含来自 glib 的标头

如何让 musl-gcc 使用 musl 标头但仍包含 /usr/include 中的其他文件？

我想用自定义版本的 musl 构建静态 Rust 可执行文件。作为第一步，我让自己熟悉 Rust 的构建系统。

我采用了稍微过时的docker-rust-muslGitHub 项目并更新了过时的 URL。一切似乎都适用于构建，但是当我想用编译器编译时x86_64-unknown-linux-musl找不到 musl stdcrate：

实际上，/usr/local/lib/rustlib/仅包含x86_64-unknown-linux-gnu目录，即使构建期间的输出表明x86_64-unknown-linux-musl已构建：

但是，当涉及到安装步骤时，x86_64-unknown-linux-gnu却无处可寻：

x86_64-unknown-linux-musl安装Rust 标准库我需要做什么？

进步：

挖掘构建环境后发现，它make all构建了 Ruststd库，musl但后续make install步骤不会安装它。我们在前面提到的 docker 镜像的脚本中有一个临时修复。build.sh目前尚不清楚这是构建环境的问题还是其使用的问题。

Rust 开发人员知道这个问题。但是，没有修复的 eta。