This is actually why we finally pushed to change the direction of R1 somewhat. We still have quite a few people who really want a BeOS ABI compatible version of Haiku (which was the original R1 target for all these years), but a riff was forming of people who wanted to use the more modern gcc builds without the gcc2 stuff and get neat modern things that don’t easily compile on gcc2 like modern mesa + llvm accelerated OpenGL rendering, clang, etc.
As of a few months ago, we had the following architectures we built nightlies images for. Anyone could download any mix of images and install them on their systems.
- x86_gcc2 hybrid (gcc2 + gcc5) *
- x86 hybrid (gcc5 + gcc2)
- x86_64 *
- arm *
- powerpc *
Everyone was running their own architecture… while R1 was targeting only x86_gcc2hybrid.
In the last few months, we were finally able to come together and start narrowing our focus.
We still build Haiku in all the flavors above on every commit to test for breakages, but no longer produce nightly/downloadable images for them (the ones with a * above we produce nightly images for)
Since gcc2 was only ever used for 32-bit, x86_64 gives us a nice transition from BeOS to more modern systems.
- 32-bit “Haiku gcc 2 hybrid + BeOS ABI compatible”
- 64-bit “Haiku gcc 5.x - No BeOS ABI compatibility”
- 64-bit “Haiku gcc 5.x+” - No BeOS ABI compatibility"
Nightly images (for now, maybe arm on R2?? who knows)
- “non-x86 ports” nightlies (arm, powerpc, etc)
When R1 comes out, both 32-bit and 64-bit should be well supported. Right now we’re just beginning to ramp up mass package builds, so any kind of core binary change to the OS has the potential to “break a bunch of packages” and it takes us a little while to absorb the changes and get new packages out.
(There is a little chatter of R2 having 64-bit with some 32-bit BeOS compatible gcc2 environment you could install via a package… but that would require us to add the ability to run 32-bit code on 64-bit Haiku installations)