Can we make the x86 a first-class target architecture, similarly to x86_64, x86_gcc2 and riscv64?
Currently to build a 32-bit Haiku image locally, one would need either to go with x86_gcc2, which is impossible to build on a Mac, or to tinker with x86 arch by bootstrapping it locally, which involves a “build the whole world” marathon (ask me how I know )
I assume, we would need to setup a haikuports builder, and probably a nightly pipeline. Would it be okay (wrt to available hardware resources) to add them?
Can you not build on something that isn’t a mac? or even in a VM inside a mac?
That sounds like a reason to fix x86_gcc2 building on mac, not to add a new architecture.
I am curious, what fails when you try to build x86_gcc2 on mac?
I don’t understand why we persist with this arch. I mean can’t we let it die? Who realistically is using that binary compatibility with BeOS apps from 20 years ago?
Maybe I don’t understand the situation…
I’m 100% behind deprecating x86_gcc2 immediately and switching to recent gcc + x86 for those who can’t run 64bit.
It used to be it’s own arch, but iirc was discontinued because it did not provide any benefit to keep around (you still have to care about gcc2 compat everywhere both compilers are used, and the x86 arch did not give anything in addition)
Personally I think we could re-organize the files/dir layouts a bit so all these arches can be co-installed. Would also be nice in order to run foreign arch code with qemu user or so.
Aside my main 64-bit Haiku, I have an old netbook running x86_gcc2 and it works great. It basically revived that old machine in an era when most GNU/Linux distros either dropped 32-bit or made it work only if you are not yet another victim of glibc incompatibility (I am, since glibc 2.36). Even FreeBSD dropped 32-bit, announcing there will be no x86 branch in its next major release. But those old machines are not dead yet, they can still be useful. Haiku is one of the few remaining choices for this hardware.
Despite still using Haiku 32-bit, I must admit I almost never use “the gcc2 part” — but not because it is obsolete. GoBe Productive was ahead of its time, back when the corresponding M$ stuff was the definition of absolute crap (it still is, but that’s another story). I just have no real need for an Office suit. Still, I can see why we have x86_gcc2 and not just x86. I honestly don’t see why dropping it. Your “pure” x86 is just one setarch x86 away, which you can embed in scripts amd never actually type it either.
In case it was not clear, I don’t ask x86_gcc2 arch to be removed, deprecated or modified in any way, so let’s not continue the off-topic discussion. My request is specifically about the x86 arch being bootstrapped and ready for fast local build.
Can you elaborate more on this? If I bootstrap and build x86 locally, there’s gcc2 in that build, right?
I can, in the same way as I can run a bootstrap build on Mac, meaning it will considerably slow down the rebuild cycle for me. Btw, it would be more efficient to use Docker instead of a full Linux VM. I’ll give it a try for a regular x86_gcc2 build.
These are two orthogonal topics. Also, it’s not that we would be adding a new architecture. The architecture is already in place, but the haikuports packages necessary for the x86 build are not provided by the Haiku CDN, so one needs to bootstrap them locally.
The build of the cross-tools-x86_gcc2 fails. Always has been (c). Mac OS was not a thing when gcc2 was released, so there’s simply no configuration rules necessary to build it on a Darwin host, modern or not.
The main problem we have with our code, that is Haiku internal code, is that we have to make it conform to two seperate compilers, the gcc2 and the modern version. So if you develop code and targeted the x86 arch you then still had to care that the code builds with gcc2, otherwise you would break the x86_gcc2 arch instead then.
The “dual” architecture is a bit of a compromise here, some parts, like the kernel, are not build with gcc2 anymore so do not have to care about this at all.
I’m not sure. But my idea is basically to eliminate x86 as a sub-arch for x86_gcc2 as far as haikuports is concerned, and re-organize the folders a bit so “native” x86 packages can be installed on the hybrid arch right next to the x86_gcc2 packages. i.e mounted to a common “root/x86”.
If I am not mistaken this should allow to kill the sub-architecture shenanigans in haikuports completely, and not build anything got x86_gcc2 there again.
So now you would only be left with the kernel (x86) and two sets of userland libs, and in your case you could be able to choose to only compile one set of them.
Well, first off parts of our C library are based on musl’s code, and secondly, what would the point be? Either stuff in C is portable, in which case sure you can just use another implementation if you want, or it is OS specific, in which case having a second implementation doesn’t make make sense. (For example our C Library has stubs for calling specific system calls; since this is the “source of truth” for the system call numbers on any given systems you can’t really replicate this… so should just use the stubs provided)
)