My goal is simple: I would like to create a program that bootstraps the nix package manager on any architecture, as a non-root user, with as few depends as possible. For now, what I did is the following: I download on the host a minimalist alpine version, with the good arch. Then I untar it, and "chroot" (in fact proot) into it. Then, I install (in the chroot) all the deps for the build, I build it with the good options, and then I copy back the files on the host.

But there is an important problem: each system seems to have the "interpreter file" (the thing you get when you run file on it) in a different place: on my debian it's in /lib64/ld-linux-x86-64.so.2, but on alpine it's in /lib/ld-musl-x86_64.so.1. So when I run it, I get an error like File does not exists (while it obviously exist).

So here is my question: how can I compile a tool (like nix), so that the interpreter is sure to be found on all (or at least most) of the linux distributions ? And if it's not possible, can I, somehow chroot/proot into a system, and use the host interpreter, so that when I copy back the files on the host the interpreter becomes the good one ?

Thank you!

  • @StephenKitt we say in French something like: "I will go to bet less bumd" thanks I have remote my inaccurate / wrong comments – Kiwy Mar 14 '18 at 15:20

There are three ways to deal with this kind of problem.

  1. You can build nix statically; then it won’t need a dynamic linker at run-time, and will work pretty much anywhere. (This also deals nicely with library compatibility issues.)

  2. You can build nix several times, once per target libc — realistically, on Linux, GNU libc and musl (maybe dietlibc too). This will give you binaries which you can use as appropriate depending on the target environment’s libc. I don’t know about Alpine Linux, but this is possible for example on Debian; you’d build using the default compiler to build with GNU libc, and install the musl-dev package and build with musl-gcc to target musl.

  3. You can specify the dependencies of whatever binary you do decide to build, and install them on the target environment. For example, a musl-based binary built on Alpine will be easier to run on a Debian derivative if you install the musl package there.

  • Thank you for your answer. Do you mean that if the package is statically linked, then no library at all are needed even for the libc... interpreter ? I thought that this was needed also in static build because I got some problem with that at some time (with AppImage I think, they always need a libc, don't know why then), but maybe I just did it wrong... I'll try to compile nix statically and let you know. And on 2) you need to produce one binary for each version right, and let the user choose? – tobiasBora Mar 14 '18 at 23:56
  • That’s right, static linking means the binary doesn’t need external libraries (except some NSS libraries in some cases), and yes, in variant 2 you need one binary for each version, and let the user choose (or write a wrapper script). – Stephen Kitt Mar 20 '18 at 14:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.