On Sun, 27 Oct 2024, Thorsten Glaser wrote:
That seems to imply that someone requires that those packages are
ported.
Yes, we do. Rust especially is killing the entire FOSS ecosystem.
These all are conditio sine qua nōn when it comes to continuing
Linux/m68k, as a whole.
I think that's overstating the case. Alternatives to rust are available
and will be for the foreseeable future. Most notably,
https://safecpp.org/draft.html
I agree with your sentiment though, in that rust generally gets a lot of
funding and hype. Even if the Rust Foundation doesn't care about
supporting the backend for m68k, there is still a way for non-commercially
viable platforms to collaborate. In particular,
https://gcc.gnu.org/wiki/RustFrontEnd
Absent the right conditions, perhaps it is best focus limited porter and
developer effort on patching only those packages that are really required.
I tried my hand at Qt5. About 20 man-hours in I essentially gave up,
and that was without even getting to something I could put to a
compile and runtime test.
I take your point about the amount of effort required (and the lack of
resources). The answer may be to share the work better by enabling more
collaboration.
It appears that NetBSD/m68k has naturally aligned ints. Perhaps you could
look at adding kernel support for their ABI, and get access to Qt and LLVM
that way, without impacting the existing ABI and its ecosystem.
BTW, it has long annoyed me that two different 68k Mac bootloaders exist,
one each for Linux and NetBSD, which are duplicated effort, and have
different sets of bugs. To my mind, this is another good opportunity to
collaborate and avoid wasted developer effort (perhaps by dual licensing).
“Natural” alignment of data types has essentially become a requirement
these days, and m68k is the only true outlyer (i386 could in theory, but
the Unix psABI designers were sensible enough to not do it).
I expect alignment assumptions like that will end up putting more
platforms in the same predicament in future. "Natural" alignment is
meaningless in the context of portable data structures, as they exist
without reference to any particular integer unit. It is because your
struct patches improve portability that I'd expect those patches to remain
acceptable upstream.
Q. What is the size of this struct, assuming baa.b is naturally aligned?
struct baa {
int a;
long long b;
};
