x86_64 is used as a baseline: the "x86_64" entry, whatever status it has,
is transformed into "all", and then the other entries in ARCHITECTURES
either dropped or rearranged appropriately.
Reworking the Haiku backend from 6.3 (2004) to 8.1 (2018) surprisingly
only took a few hours to get it to compile ... but then it crashes when
attempting to start inferiors with a use-after free that I spent over
three hours debugging and got nowhere.
It seems that somehow, an event object that is created, deleted, and otherwise
managed entirely by the Haiku patches is somehow deleted between waits?!
The guarded heap was of not much help here, it obviously caught the UAF
before the regular heap did, but couldn't even say where it had been freed,
only where it had been allocated; and the allocation location looked
completely wrong also. So, this is very close, but it doesn't work just yet.
It would sure be nice to have Qt Creator's GDB support (which needs
Python-enabled GDB) working...
This is the same version we have in-tree, so we can now outsource that
version. AFAICT, it works just as well as the version included in the "haiku"
package.
I've left the static libs in the main package as that seems to be the
convention among Linux distros.
* Referring the current haiku version explicitly is not needed, since
the RequiresUpdater takes care of setting the version of Haiku used
for building a package.
waddlesplash