我的目标很简单：我想创建一个程序，以非 root 用户的身份在任何架构上引导 nix 包管理器，并且依赖尽可能少。现在，我所做的如下：我在主机上下载了一个简约的阿尔卑斯版本，具有良好的拱门。然后我解压它，并“chroot”（实际上是原始根）进入它。然后，我（在 chroot 中）安装构建的所有依赖项，使用良好的选项构建它，然后将文件复制回主机上。
但有一个重要的问题：每个系统似乎file在不同的地方都有“解释器文件”（运行时得到的文件）：在我的 debian 上它位于/lib64/ld-linux-x86-64.so.2，但在 alpine 上它位于/lib/ld-musl-x86_64.so.1。因此，当我运行它时，我收到类似的错误File does not exists（虽然它显然存在）。
所以这是我的问题：如何编译一个工具（如 nix），以便确保在所有（或至少大多数）Linux 发行版上都能找到解释器？如果不可能，我可以以某种方式 chroot/proot 进入系统，并使用主机解释器，这样当我将文件复制回主机上时，解释器就会成为好的解释器吗？
谢谢你！
答案1
处理此类问题有三种方法。
您可以
nix静态构建；那么它在运行时就不需要动态链接器，并且几乎可以在任何地方工作。 （这也很好地解决了库兼容性问题。）您可以构建
nix多次，每个目标 libc 一次——实际上，在 Linux、GNU libc 和 musl 上（或许Dietlibc 也是如此）。这将为您提供可以根据目标环境的 libc 适当使用的二进制文件。我不了解 Alpine Linux，但是在 Debian 上这是可能的；您可以使用默认编译器来使用 GNU libc 进行构建，然后安装musl-dev包并使用musl-gccmusl 进行构建。您可以指定任何二进制文件的依赖关系做决定构建并将它们安装在目标环境中。例如，如果您在 Debian 衍生品上安装
musl软件包，那么在 Alpine 上构建的基于 musl 的二进制文件将更容易在 Debian 衍生品上运行。