6 ms·

The article says this about a musl-using statically-linked rust binary: > take that hello binary and copy it to any x86_64 machine running Linux and it’ll run

The article says this about a musl-using statically-linked rust binary: > take that hello binary and copy it to any x86_64 machine running Linux and it’ll run just fine. Is that true? I would have assumed that musl has some kernel ABI version requirements, and won't run on older kernels (older than whatever that specific musl library was built to support).

steveklabnik 10y ago
https://www.musl-libc.org/faq.html https://www.musl-libc.org/faq.html Says 2.6 officially, due to some threading stuff on earlier versions. Should work on anything later though.
- wyldfire 10y ago
  Yes, that's an understatement. It's very uncommon to find pre-2.6 x86_64 systems.
- jjnoakes 10y ago
  This says that musl will build and run on Linux 2.6.x, but it says nothing of the binary compatibility between systems. If I build musl and statically link my program to it on one version of the Linux kernel, and then I copy that to an older version of the Linux kernel (both 2.6 or greater), I'm extremely skeptical that it would just work (especially for any two arbitrary versions above 2.6).
  - steveklabnik 10y ago
    My understanding is that the kernel goes to pretty great lengths to not break ABI compatibility, so this should be fine. I just tried it out with a server I have lying around: https://gist.github.com/steveklabnik/0b2736642ddd4669260bd7fbb9a70787 https://gist.github.com/steveklabnik/0b2736642ddd4669260bd7f... Compiled on 3.16.0-4-amd64, ran on 3.2.0-4-amd64, no issues
    - jjnoakes 10y ago
      I expected it to work for most cases - especially trivial ones like that. Where I was skeptical was around new features added to the kernel. I do not know how careful musl is when it is built on a kernel which includes a new feature (say something like F_DUPFD_CLOEXEC, added in 2.6.24), but is then copied and run on an older kernel (2.6.10) which would return -EINVAL from that system call. A quick glance at the musl sources shows that in this particular case musl is careful to notice the -EINVAL and emulate it (via F_DUPFD and F_SETFD FD_CLOEXEC). But without seeing documentation from musl that this is guaranteed for everything that could be added in later kernels (I'm not even sure everything added could be emulated easily, but perhaps it could be), then I'd still be skeptical making the claim that musl and Rust could be statically linked on any version of Linux after 2.6 and run on any other version of Linux after 2.6. It's not really about the kernel ABI being compatible (programs built on older kernels run on newer ones quite nicely). It's about newer features from newer kernels still being supported (or their absence detected and their features emulated) on older kernels. That's a property of musl, not of the kernel.
      - steveklabnik 10y ago
        Gotcha, that does make sense. I tried looking around for more information about specifics here, but couldn't really find anything. I did think that musl was attempting to deal with this, but without something explicitly saying it, I am wondering if that's something that I misunderstood, or just heard somewhere.
      - justincormack 10y ago
        For libc functions (man 3) it will emulate if the syscall doesn't work. If you are making a system call directly (man 2) it is up to your code to do a fallback, more or less.
        jjnoakes 10y ago
        First, my example was fcntl(2), which musl is emulating. So that doesn't fit your "rule". Second, is your "rule" documented anywhere for musl? That's what I'm looking for - an indication by the musl project that such a thing is supported (binary compatibility from newer to older Linux kernels, and if so, what version range). Without such a project-sanctioned statement, I'm afraid I stand by my position that the blog's assertion that the statically-linked rust-musl binary can be copied to any Linux 2.6.x machine (or newer) and just run without any issues. I would agree that any statically-linked rust-musl binary could be built on a Linux kernel and then run on a later Linux kernel, but earlier, well that's up to the musl project to say.

steveklabnik 10y ago

https://www.musl-libc.org/faq.html https://www.musl-libc.org/faq.html Says 2.6 officially, due to some threading stuff on earlier versions. Should work on anything later though.

wyldfire 10y ago
Yes, that's an understatement. It's very uncommon to find pre-2.6 x86_64 systems.
jjnoakes 10y ago
This says that musl will build and run on Linux 2.6.x, but it says nothing of the binary compatibility between systems. If I build musl and statically link my program to it on one version of the Linux kernel, and then I copy that to an older version of the Linux kernel (both 2.6 or greater), I'm extremely skeptical that it would just work (especially for any two arbitrary versions above 2.6).
- steveklabnik 10y ago
  My understanding is that the kernel goes to pretty great lengths to not break ABI compatibility, so this should be fine. I just tried it out with a server I have lying around: https://gist.github.com/steveklabnik/0b2736642ddd4669260bd7fbb9a70787 https://gist.github.com/steveklabnik/0b2736642ddd4669260bd7f... Compiled on 3.16.0-4-amd64, ran on 3.2.0-4-amd64, no issues
  - jjnoakes 10y ago
    I expected it to work for most cases - especially trivial ones like that. Where I was skeptical was around new features added to the kernel. I do not know how careful musl is when it is built on a kernel which includes a new feature (say something like F_DUPFD_CLOEXEC, added in 2.6.24), but is then copied and run on an older kernel (2.6.10) which would return -EINVAL from that system call. A quick glance at the musl sources shows that in this particular case musl is careful to notice the -EINVAL and emulate it (via F_DUPFD and F_SETFD FD_CLOEXEC). But without seeing documentation from musl that this is guaranteed for everything that could be added in later kernels (I'm not even sure everything added could be emulated easily, but perhaps it could be), then I'd still be skeptical making the claim that musl and Rust could be statically linked on any version of Linux after 2.6 and run on any other version of Linux after 2.6. It's not really about the kernel ABI being compatible (programs built on older kernels run on newer ones quite nicely). It's about newer features from newer kernels still being supported (or their absence detected and their features emulated) on older kernels. That's a property of musl, not of the kernel.
    - steveklabnik 10y ago
      Gotcha, that does make sense. I tried looking around for more information about specifics here, but couldn't really find anything. I did think that musl was attempting to deal with this, but without something explicitly saying it, I am wondering if that's something that I misunderstood, or just heard somewhere.
    - justincormack 10y ago
      For libc functions (man 3) it will emulate if the syscall doesn't work. If you are making a system call directly (man 2) it is up to your code to do a fallback, more or less.
      - jjnoakes 10y ago
        First, my example was fcntl(2), which musl is emulating. So that doesn't fit your "rule". Second, is your "rule" documented anywhere for musl? That's what I'm looking for - an indication by the musl project that such a thing is supported (binary compatibility from newer to older Linux kernels, and if so, what version range). Without such a project-sanctioned statement, I'm afraid I stand by my position that the blog's assertion that the statically-linked rust-musl binary can be copied to any Linux 2.6.x machine (or newer) and just run without any issues. I would agree that any statically-linked rust-musl binary could be built on a Linux kernel and then run on a later Linux kernel, but earlier, well that's up to the musl project to say.