问题标签 [musl]

我有一个当前动态链接到glibc. 这个库动态加载到一个应用程序中，该应用程序也动态链接到glibc. 我无法控制应用程序，只能控制共享对象。

但是，有时加载库会导致应用程序获取SIGKILLd，因为它具有非常严格的实时要求并rlimit相应地设置。用分析器查看这个告诉我，大部分时间实际上都花在了链接器上。所以本质上动态链接实际上太慢了（有时）。好吧，这不是我曾经想过的问题:)

我希望通过生成一个静态链接的共享对象来解决这个问题。但是，谷歌搜索这个问题并阅读多个其他 SO 线程警告我不要尝试静态链接 glibc。但这些似乎是 glibc 特有的问题。

所以我的问题是，如果我要静态链接这个共享库musl，然后让它（动态链接）glibc 应用程序dlopen，那会安全吗？多个libc一般有问题吗？

我正在尝试为我的 linux 构建 gcc。我正在交叉编译，因为我没有预先存在的 gcc。

我正在使用 musl 作为 libc。

我这样配置 gcc：

当我运行makegcc 编译几分钟。一段时间后，构建尝试执行以下操作

在我的构建目录x86_64-unknown-linux-musl/libgcc中失败：

我验证了objdump -t crt1.o这些objdump -t Scrt1.o目标文件定义main，它们确实如此。

我现在很困惑，因为名字libgcc暗示它是一个库，当然没有main方法。为什么ld期待一个？构建在这里试图做什么？

我在 dockerhub 上试用了 muslcc 图像，但无法运行已编译的 Hello World 程序。

我使用的图像是：muslcc/i686:x86_64-linux-musl（在此处找到）。我加载图像：

这样我就可以在本地机器上编码，并在 musl 图像上编译和测试。

我正在编译的程序是一个基本的 hello world：

此文件另存为helloworld.c

我运行gcc -Wall helloworld.c并进入a.out同一目录。做ls -l给我：

当我尝试a.out使用:运行时./a.out，我得到：

我还尝试指定一个输出文件，以防这是默认输出的一些问题，但没有运气。我也尝试过绝对路径，/var/a.out但也没有运气。

-- 编辑：

1. 我检查过了，./符号在 $PATH

我在下面突出显示了两个问题。我正在使用 64 位 Linux。

我在另一篇文章中看到了作为实现提到的另一个帖子。MUSLlibc

我尝试将它与以下使用两个函数的Hello world汇编程序一起使用，并且.libcwrite_exit

我组装了代码：

然后我跑来ld生成一个静态链接的可执行文件MUSL libc。

这会生成一个a.out按预期工作的文件，在执行时输出“Hello, world”。

我还尝试了对前面ld命令的不同调用，使用-static -lc而不是直接指定路径，并且还使用-L给出路径MUSL以便glibc不使用，因为后者已经在ld的搜索路径上。

这按预期工作。

接下来我尝试动态链接MUSL libc.

这似乎按预期工作。我可以运行a.out，并调用ldd显示'sa.out已链接。MUSLlibc

最后，我尝试了相对于之前的静态链接版本的类似修改，使用-lc而-L不是.so直接指定文件的路径。

程序运行不正常，输出错误：

当我使用标志运行相同ld的命令时--verbose，输出与传递--verbose给早期ld命令（Command 4生成工作可执行文件）时的输出相同。

运行lddona.out也会输出错误：

问题1：为什么在这种情况下调用ld和-L与-lc之前的行为不匹配，我.so直接指定了文件？

我注意到，如果我将指定的动态链接器更改为/lib/ld-musl-x86_64.so.1，生成的a.out将按预期运行。

但是，调用lddgenerateda.out会产生以下错误，而之前我没有使用-lcand -Lin时，情况并非如此Command 4：

问题 2：为什么ld这个二进制文件会失败，但是当我将.so文件的路径传递给ldd并使用不同的动态链接器时更早地工作？

我们有基于 alpine linux 的 docker 文件。我想让构建的容器检查musl库的版本，我的意思是运行容器并在 RT 中检查 musl 版本，我该怎么做？

我试过类似的东西

并运行

得到

要使用 glibc 构建 c11 线程程序，我仍然需要与 -lpthread 链接，为什么？glibc 2.28 声称支持 c11 线程，但为什么我还需要 pthread？

musl 可以在没有 pthread 的情况下构建 c11 线程。

直到昨天，一切都照常进行。今天早上我试图打开一个项目，我遇到了这样的错误：

我完全迷路了，自昨天以来我的系统没有任何变化，因此我想知道是否有人遇到过类似的问题？

它发生在版本3.1.302和3.1.401.NET Core SDK 中。

我在带有5.4.0-42-generic内核的 Ubuntu 20.04.1 上。

这是来自musl的源代码：

我很好奇第 6 行和第 14 行的目的是什么（从链接源重新编号）。

据我了解，代码的开头测试了作为第一个参数传递的指针的目标（第 3-5 行），第 6 行然后将指针移动到r11和第 14 行然后将其移动到堆栈上使用的位置通过第 7 个参数。

这似乎没有用。这些动作有什么作用吗？

我正在尝试在 Alpine Linux 上编译Box86 ，这是一个使用musl libc 实现而不是glibc的 Linux 发行版。在完成 46% 时，编译停止并出现以下错误：

自然，我的第一直觉是查找这些名称并弄清楚它们的用途，以便找到合适的替代品，但我运气不佳，这导致我的问题是：这些以 - 为__NR_前缀的符号是什么，以及他们在做什么？

我正在尝试在 x86_64 Debian 内核 v4.19 上使用 musl 工具链构建MariaDB v10.3 。我主要是使用包装器来实现这一点。我安装的相关包如下：musl-gcc gcc

• musl(1.1.21-2)：标准 C 库
• musl-dev(1.1.21-2)：标准C库开发文件
• musl-tools(1.1.21-2)：标准C库工具

为了构建 MariaDB，我首先运行：

它干净地退出，然后我跟进：

带有以下消息的错误：

现在我知道 musl 正在寻找的库 ( libgcc_s.so) 位于其中，/lib/gcc/x86_64-linux-gnu/8/但我尝试使用LDFLAGS或符号链接该库来包含该库的尝试/usr/lib/x86_64-linux-musl/失败了。

我要以正确的方式编译 MariaDB 吗？我想我做错了什么，因为 Alpine Linux 可以运行它。