Finn Thain dixit:
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,
That’s not the point. Google, for example, are aggressively funding
people to throw away perfectly working code and rewrite it in rust,
or to at least add rust to projects. librsvg has been such a case for
some time already, python-cryptography is, but now we’re losing even
freetype (!!!) and, possibly, even the Linux kernel.
https://gcc.gnu.org/wiki/RustFrontEnd
That’s assuming it can build the same stuff the same way so it can
be used in packaging.
I expect alignment assumptions like that will end up putting more
platforms in the same predicament in future.
No, all the other platforms use natural alignment.
"Natural" alignment is meaningless in the context of portable data
structures, as they exist without reference to any particular integer
Yeah, but in practice, all we have is ILP32 and LP64; the Windows®
world has LLP64 in addition. And natural alignment just means that
all the data types’ alignment is their size. (Which kind of makes
sense, so you can read them without getting an unalignment trap on
SPARC or so.)
Q. What is the size of this struct, assuming baa.b is naturally aligned?
struct baa {
int a;
long long b;
};
For ILP32, LP64 and LLP64, it’s 4 (a) + 4 (padding) + 8 (b) = 16 chars.
More importantly, and relevant for Qt, struct baa is also 8-byte
aligned, and malloc(3) results are usually 8‑ or even 16-byte aligned.
bye,
//mirabilos
--
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)