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; };
