4 ms·

I've seen some people gladly using nightly rust but restricting themselves with the GCC and CMake that comes with CentOS 6. The damage done by distributions shi

I've seen some people gladly using nightly rust but restricting themselves with the GCC and CMake that comes with CentOS 6. The damage done by distributions shipping development toolsets is never-ending.

mroche 8y ago
There’s a DTS that ships Rust 1.26 (rust-toolset-7), however, it requires RHEL/CentOS 7. Red Hat’s been doing a pretty good job with providing newer toolkit’s through the DTS system, but some of them didn’t find their way to RHEL 6.
- steveklabnik 8y ago
  They also announced this recently: https://developers.redhat.com/blog/2018/11/20/support-lifecycle-for-clang-llvm-go-and-rust/ https://developers.redhat.com/blog/2018/11/20/support-lifecy...
kbenson 8y ago
> The damage done by distributions shipping development toolsets is never-ending. You say that, but we've already come out the other end of the period where linux was still on the upward swing of popularity and if a development toolchain wasn't as easily available a lot of software may never have taken off as quick. The ability to easily install a development toolset to compile (even if safely hidden behind a script to download and compile something like Ruby, Python, Perl, or a module for one of them) is a major boon, even if just used to create packages for the distribution's package system for local distribution (e.g. creating an RPM from spec). Given the choice between an easily installable default that might get old or no first party option provided, having a default available is vastly better. Blame companies for poor options they choose, not the people and organizations that do their best to provide even a single option.
jjnoakes 8y ago
The biggest reason (for me anyway) to restrict which gcc I use (and stick to the system-provided one) is so I don't need to distribute libstdc++ and libgcc_s with my program. The RedHat devtoolset was a nice solution to this (use a newer gcc version, but link to the system libraries), but if that isn't available, then building with the system compilers helps in this area. Rust doesn't have this problem when rust programs are statically linked, but if distros start shipping rust shared libraries which other programs start depending on, and/or some of the rust standard lib ends up in a system shared library, some of the same issues may arise (or maybe not, rust may have solved them in a clever way).
- steveklabnik 8y ago
  It's not the end of the world for distros; they pick a single Rust version, and so shared libraries work for them. They do need to recompile the world when they update the compiler, but it's a single recompile each time.
  - jjnoakes 8y ago
    Right - and so you get same situation that you have in C++-land (if I'm understanding you correctly) where compiling arbitrary rust programs with the distro compiler level may benefit you if you want to depend on the system-provided rust shared libraries.
    - steveklabnik 8y ago
      Yep.
- gdy 8y ago
  DLL hell on Linux.
  - jjnoakes 8y ago
    Not really; there's a few substantial differences between shared objects with SONAMEs and link-time vs run-time file system names and LD_LIBRARY_PATH and /etc/ld.so.conf vs DLLs and searching PATH (starting with "."). I don't know much about modern Windows (SxS, etc) so things may have improved there, but last I looked (a while back admittedly) DLL hell and shared object issues were in different leagues.
    - gdy 8y ago
      Well, I might have misunderstood the original problem. >so I don't need to distribute libstdc++ and libgcc_s with my program Could you explain why you want to avoid that?
flukus 8y ago
That's because the libraries come from the same source and work together. Rust/cargo is it's own little universe ignoring the rest of the system.
marcosdumay 8y ago
That's mostly because those two are stable, and there is near to no gain on going into the bleeding edge. When people gain something from an upgrade, they do it.

mroche 8y ago

There’s a DTS that ships Rust 1.26 (rust-toolset-7), however, it requires RHEL/CentOS 7. Red Hat’s been doing a pretty good job with providing newer toolkit’s through the DTS system, but some of them didn’t find their way to RHEL 6.

steveklabnik 8y ago
They also announced this recently: https://developers.redhat.com/blog/2018/11/20/support-lifecycle-for-clang-llvm-go-and-rust/ https://developers.redhat.com/blog/2018/11/20/support-lifecy...

kbenson 8y ago

> The damage done by distributions shipping development toolsets is never-ending. You say that, but we've already come out the other end of the period where linux was still on the upward swing of popularity and if a development toolchain wasn't as easily available a lot of software may never have taken off as quick. The ability to easily install a development toolset to compile (even if safely hidden behind a script to download and compile something like Ruby, Python, Perl, or a module for one of them) is a major boon, even if just used to create packages for the distribution's package system for local distribution (e.g. creating an RPM from spec). Given the choice between an easily installable default that might get old or no first party option provided, having a default available is vastly better. Blame companies for poor options they choose, not the people and organizations that do their best to provide even a single option.

jjnoakes 8y ago

The biggest reason (for me anyway) to restrict which gcc I use (and stick to the system-provided one) is so I don't need to distribute libstdc++ and libgcc_s with my program. The RedHat devtoolset was a nice solution to this (use a newer gcc version, but link to the system libraries), but if that isn't available, then building with the system compilers helps in this area. Rust doesn't have this problem when rust programs are statically linked, but if distros start shipping rust shared libraries which other programs start depending on, and/or some of the rust standard lib ends up in a system shared library, some of the same issues may arise (or maybe not, rust may have solved them in a clever way).

steveklabnik 8y ago
It's not the end of the world for distros; they pick a single Rust version, and so shared libraries work for them. They do need to recompile the world when they update the compiler, but it's a single recompile each time.
- jjnoakes 8y ago
  Right - and so you get same situation that you have in C++-land (if I'm understanding you correctly) where compiling arbitrary rust programs with the distro compiler level may benefit you if you want to depend on the system-provided rust shared libraries.
  - steveklabnik 8y ago
    Yep.
gdy 8y ago
DLL hell on Linux.
- jjnoakes 8y ago
  Not really; there's a few substantial differences between shared objects with SONAMEs and link-time vs run-time file system names and LD_LIBRARY_PATH and /etc/ld.so.conf vs DLLs and searching PATH (starting with "."). I don't know much about modern Windows (SxS, etc) so things may have improved there, but last I looked (a while back admittedly) DLL hell and shared object issues were in different leagues.
  - gdy 8y ago
    Well, I might have misunderstood the original problem. >so I don't need to distribute libstdc++ and libgcc_s with my program Could you explain why you want to avoid that?

flukus 8y ago

That's because the libraries come from the same source and work together. Rust/cargo is it's own little universe ignoring the rest of the system.

marcosdumay 8y ago

That's mostly because those two are stable, and there is near to no gain on going into the bleeding edge. When people gain something from an upgrade, they do it.