3 ms·

Sounds like this can be solved by adding support to LLVM. I realize that might be a tall order, but isn't that preferable to locking entire platforms out of a p

by l0b0 6y ago

Sounds like this can be solved by adding support to LLVM. I realize that might be a tall order, but isn't that preferable to locking entire platforms out of a popular new language forever? > The LLVM developers have been somewhat leery of taking on new architectures, unless they can be convinced there will be long-term support for them, which is understandable, but makes the problem even worse. Surely, if people actually care about these platforms there would be people willing to commit to this long term? If not, are people saying that everything needs to support all the GCC-supported platforms forever?

qchris 6y ago
I was wondering the same thing. It's not as though LLVM is some niche project that only Rust is using; it's the backend for a large number of compilers, and I imagine this will continue to be the case moving forward. There are now even languages that are written in languages that use LLVM for their backend, like gleam [1]. I think, ideally, there would be a concerted effort to extend LLVM compatibility to those platforms. But I don't think it's unreasonable to assume that there simply won't be--I sometimes run into problems on aarch64, and most of these are far more niche than that. As the article mentioned, it seems likely that eventually the ability for certain platforms for get support on new compilers will be a make-or-break for their ability to stay current with upgrades for a lot of the more fundamental packages. Alternatively, I guess, there could be effort to get a new gcc-backend for more langauges; I believe there's an ongoing effort for Rust[2], but who knows down the line what that might look like. Eventually, this will probably need to come to a head. [1] https://gleam.run/ https://gleam.run/ [2] https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs
- ece 6y ago
  If the Linux kernel also adds Rust as a dependency to build modules, gccrs could actually be a good solution for the platforms still supported by gcc. It's ok for Gentoo to drop support for these platforms IMO, the least used architectures need to be relegated to the museum sometime.
panny 6y ago
Why doesn't rust team add support for GCC instead? Seems like that would be a big win for them. Alternately, python cryptography could have chosen a different memory safe language, like Go, which is supported by GCC. Why did they intentionally choose a poorly fit language like Rust? Use the best tool for the job, yes?
- adrianN 6y ago
  For historic reasons GCC is architected to be much more difficult to use as a backend.
  - arp242 6y ago
    More ideological reasons than historic ones. As far as I know, they're still concerned with the whole "someone might steal our frontend or backend!" thing, unless I missed something and this attitude changed?
    - SubjectToChange 6y ago
      AFAIK, the fear was that people would implement proprietary plugins for GCC and not upstream their changes and improvements. The classic Embrace, Extend, and Extinguish. Emacs modules were delayed for a long time for the same reason, RMS only approved them on the condition that they export GPL symbols. LLVM has changed the situation quite a bit though. GCC could make itself easier to hack on but it might be too late.
      - qalmakka 6y ago
        The irony of it is that no one was really interested in making a new frontend. LLVM was meant to be submitted to GNU, but RMS didn't really show interest in the 00's and instead it rebuffed attempts to disentangle GCC's frontend from the backend, forcing the creation of Clang. It's arguably true that RMS's zealotry actually backfired spectacularly.
        6y ago
viraptor 6y ago
> Surely, if people actually care about these platforms there would be people willing to commit to this long term? In some cases more than others. I feel the pain of people who want to keep running private unique architectures. I wish it would be easier for them. But mentioning s390? Companies that bought mainframes from IBM don't get to complain about compatibility with open source projects in my opinion. They can deal with that issue themselves and contribute back. (Or fund a solution) Show me how much extra you spent on wages and contracts related to that choice and I'll show you my tiniest violin.
- mjg59 6y ago
  And bear in mind that this is s390, not s390x. s390 is a 31-bit architecture that was superseded in 2000 by the 64-bit Z series, and support in the Linux kernel was dropped in 2015.
- technion 6y ago
  I had this with one of my own projects - a complaint that it didn't support an s390. I proposed a patch based on the described issue and stated it would be merged the moment someone who actually had an s390 tested it. Noone came forward. I'm certain a lot of these compatibility complaints fall into a similar area.
pca006132 6y ago
I think it would also take some effort to add support for new platforms in rust, even if LLVM already supports the platform. The `std` library is pretty large, and it would take effort porting it. (nvm if their code is `nostd`)
Groxx 6y ago
Yeah, the tradeoffs seem to be "add various gentoo/arch support to llvm" vs "nobody should use llvm for anything popular, because gentoo can't use it on abnormal architectures" Put some of this upset-energy into building out gentoo+llvm. There's no way you're going to convince the entire programming world to stop using llvm at this point, even if you claim it's reasonable.
cbmuser 6y ago
FWIW, an M68k backend for LLVM is on its way upstream (see reviews.llvm.org and search for "M68k").

by l0b0 6y ago

qchris 6y ago

I was wondering the same thing. It's not as though LLVM is some niche project that only Rust is using; it's the backend for a large number of compilers, and I imagine this will continue to be the case moving forward. There are now even languages that are written in languages that use LLVM for their backend, like gleam [1]. I think, ideally, there would be a concerted effort to extend LLVM compatibility to those platforms. But I don't think it's unreasonable to assume that there simply won't be--I sometimes run into problems on aarch64, and most of these are far more niche than that. As the article mentioned, it seems likely that eventually the ability for certain platforms for get support on new compilers will be a make-or-break for their ability to stay current with upgrades for a lot of the more fundamental packages. Alternatively, I guess, there could be effort to get a new gcc-backend for more langauges; I believe there's an ongoing effort for Rust[2], but who knows down the line what that might look like. Eventually, this will probably need to come to a head. [1] https://gleam.run/ https://gleam.run/ [2] https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs

ece 6y ago
If the Linux kernel also adds Rust as a dependency to build modules, gccrs could actually be a good solution for the platforms still supported by gcc. It's ok for Gentoo to drop support for these platforms IMO, the least used architectures need to be relegated to the museum sometime.

panny 6y ago

Why doesn't rust team add support for GCC instead? Seems like that would be a big win for them. Alternately, python cryptography could have chosen a different memory safe language, like Go, which is supported by GCC. Why did they intentionally choose a poorly fit language like Rust? Use the best tool for the job, yes?

adrianN 6y ago
For historic reasons GCC is architected to be much more difficult to use as a backend.
- arp242 6y ago
  More ideological reasons than historic ones. As far as I know, they're still concerned with the whole "someone might steal our frontend or backend!" thing, unless I missed something and this attitude changed?
  - SubjectToChange 6y ago
    AFAIK, the fear was that people would implement proprietary plugins for GCC and not upstream their changes and improvements. The classic Embrace, Extend, and Extinguish. Emacs modules were delayed for a long time for the same reason, RMS only approved them on the condition that they export GPL symbols. LLVM has changed the situation quite a bit though. GCC could make itself easier to hack on but it might be too late.
    - qalmakka 6y ago
      The irony of it is that no one was really interested in making a new frontend. LLVM was meant to be submitted to GNU, but RMS didn't really show interest in the 00's and instead it rebuffed attempts to disentangle GCC's frontend from the backend, forcing the creation of Clang. It's arguably true that RMS's zealotry actually backfired spectacularly.
      - 6y ago

viraptor 6y ago

> Surely, if people actually care about these platforms there would be people willing to commit to this long term? In some cases more than others. I feel the pain of people who want to keep running private unique architectures. I wish it would be easier for them. But mentioning s390? Companies that bought mainframes from IBM don't get to complain about compatibility with open source projects in my opinion. They can deal with that issue themselves and contribute back. (Or fund a solution) Show me how much extra you spent on wages and contracts related to that choice and I'll show you my tiniest violin.

mjg59 6y ago
And bear in mind that this is s390, not s390x. s390 is a 31-bit architecture that was superseded in 2000 by the 64-bit Z series, and support in the Linux kernel was dropped in 2015.
technion 6y ago
I had this with one of my own projects - a complaint that it didn't support an s390. I proposed a patch based on the described issue and stated it would be merged the moment someone who actually had an s390 tested it. Noone came forward. I'm certain a lot of these compatibility complaints fall into a similar area.

pca006132 6y ago

I think it would also take some effort to add support for new platforms in rust, even if LLVM already supports the platform. The `std` library is pretty large, and it would take effort porting it. (nvm if their code is `nostd`)

Groxx 6y ago

Yeah, the tradeoffs seem to be "add various gentoo/arch support to llvm" vs "nobody should use llvm for anything popular, because gentoo can't use it on abnormal architectures" Put some of this upset-energy into building out gentoo+llvm. There's no way you're going to convince the entire programming world to stop using llvm at this point, even if you claim it's reasonable.

cbmuser 6y ago

FWIW, an M68k backend for LLVM is on its way upstream (see reviews.llvm.org and search for "M68k").