3 ms·

For bootstrapping it in and for a distro that's the right thing, but if we want to have access to the rustup toolchains and targets, then those require musl-hos

For bootstrapping it in and for a distro that's the right thing, but if we want to have access to the rustup toolchains and targets, then those require musl-hosting support upstream in order for rustup binaries to be made available which, like on Windows or FreeBSD, are downloaded and used by rustup. Building rust right now takes enough time that it's hard to recommend a hypothetical from-source mode for rustup that works similar to OCaml's `opam switch compiler-vsn`. If building rustc becomes similarly fast, this can be a good alternative. And in that case having a rustc version in the distro is very useful, as long as it's not older than two releases.

steveklabnik 10y ago
Right. But std with musl is already available from the project; this is mostly about rustc.
- throwaway161220 10y ago
  That's for targeting musl, typically used for static linking. That should work when running rustup and rustc on FreeBSD as well. What we're missing is rustc-on-musl and with that rustup-on-musl.
- mitchty 10y ago
  Since I follow alpine linux dev a bit, I thought this: https://github.com/alpinelinux/aports/blob/master/testing/rust/APKBUILD https://github.com/alpinelinux/aports/blob/master/testing/ru... Is the port of rustc to run natively on AL? Bit outdated now but it seemed to work the last time I tried it. You'd have to enable the testing repo to use it however.
  - steveklabnik 10y ago
    Yes, throwaway (in my understanding) seems to want this from the project itself, not the distro.
    - throwaway161220 10y ago
      Is there another way to get access to the continuously updated toolchains and targets available via rustup?
      - steveklabnik 10y ago
        Well, if you had a "built-with-musl" rustup, then you could just use it. But if not, you can curl the s3 bucket and grab them; rustup is ultimately a convenience, not a requirement. I guess that's why I see it as "mostly about rustc", since once you have that, you can compile rustup, and once you can do that, you can get it easily. Just to be clear: I would like to see better support for all of this, personally. I'm not trying to argue that things are perfect today, just figure out exactly where in the process of getting there all this is, since I use Debian, not Alpine.
        throwaway161220 10y ago
        I feel like we're talking past each other :). Building rustup with and for musl isn't the problem. Needing glibc for the binaries downloaded by rustup is. So this is more about toolchain and target binaries for linux being libc-agnostic which is easiest to achieve by musl-static-linking them which requires upstream support. As a first step a second set of musl-dynlink, parallel to glibc-dynlink, binaries would suffice. Speaking of Debian, one has to be careful in how stuff is built for the result to run on Debian, Fedora, Arch, Suse, which is another reason to simplify things with musl since it already bundles third party C code anyway. So far rustup doesn't suffer from that, but if it ever were to dynlink ncurses or another core Linux lib, it would have the same issue as GHC's bindists. It doesn't and that's great!
        steveklabnik 10y ago
        I think so too. It happens. :)
        throwaway161220 10y ago

steveklabnik 10y ago

Right. But std with musl is already available from the project; this is mostly about rustc.

throwaway161220 10y ago
That's for targeting musl, typically used for static linking. That should work when running rustup and rustc on FreeBSD as well. What we're missing is rustc-on-musl and with that rustup-on-musl.
mitchty 10y ago
Since I follow alpine linux dev a bit, I thought this: https://github.com/alpinelinux/aports/blob/master/testing/rust/APKBUILD https://github.com/alpinelinux/aports/blob/master/testing/ru... Is the port of rustc to run natively on AL? Bit outdated now but it seemed to work the last time I tried it. You'd have to enable the testing repo to use it however.
- steveklabnik 10y ago
  Yes, throwaway (in my understanding) seems to want this from the project itself, not the distro.
  - throwaway161220 10y ago
    Is there another way to get access to the continuously updated toolchains and targets available via rustup?
    - steveklabnik 10y ago
      Well, if you had a "built-with-musl" rustup, then you could just use it. But if not, you can curl the s3 bucket and grab them; rustup is ultimately a convenience, not a requirement. I guess that's why I see it as "mostly about rustc", since once you have that, you can compile rustup, and once you can do that, you can get it easily. Just to be clear: I would like to see better support for all of this, personally. I'm not trying to argue that things are perfect today, just figure out exactly where in the process of getting there all this is, since I use Debian, not Alpine.
      - throwaway161220 10y ago
        I feel like we're talking past each other :). Building rustup with and for musl isn't the problem. Needing glibc for the binaries downloaded by rustup is. So this is more about toolchain and target binaries for linux being libc-agnostic which is easiest to achieve by musl-static-linking them which requires upstream support. As a first step a second set of musl-dynlink, parallel to glibc-dynlink, binaries would suffice. Speaking of Debian, one has to be careful in how stuff is built for the result to run on Debian, Fedora, Arch, Suse, which is another reason to simplify things with musl since it already bundles third party C code anyway. So far rustup doesn't suffer from that, but if it ever were to dynlink ncurses or another core Linux lib, it would have the same issue as GHC's bindists. It doesn't and that's great!
        steveklabnik 10y ago
        I think so too. It happens. :)
        throwaway161220 10y ago