As you know I am maintaining HaikuWebKit, the engine that powers WebPositive. The last version is not available for 32 bit as it failed to build on 32 bit systems, The compiler runs out of memory.
I tried to use clang to build, last time that worked (thanks to Waddlesplash for setting it up), but the affected file is evern larger now, and clang also runs out of memory.
I think the only solution is to cross compile it, as it is done for Iceweasel and some other software. But I’m not interested in setting that up myself. I don’t regularly use 32 bit Haiku anymore, pretty much only to build WebKit. Everything else I do on 64 bit systems now. So, someone else will have to take care of it. Until then, WebKit for 32 bit Haiku will not receive updates.
Maybe it is time for us to spin up CI builds for HaikuWebkit for both architectures?
IIRC Haiku Inc already wanted to commit to this.
(Though we should probably buy hardware and set it up somewhere instead of paying some cloud services…)
It’s not called cloud server (which means a different thing). That’s a physical dedicated server, just like in the good old days when the word “cloud” meant only a visible mass of water in the sky
We can either rent a dedicated server or buy one, and place it on colocation hosting. Both approaches have their pros and cons.
DISABLE_ASLR was enabled and appears to not be enough anymore.
WebKitLegacy and WebKit2 are the same thing. They are just two different APIs on top of the same engine, built from the same source codebase.
That’s how Haiku infrastructure used to run. It means our own admin team (which is essentially one single person) has to worry about the physical health of the machine in addition to all the other admin tasks. After several problems with hard disks showing SMART errors, we have more or less stopped doing this. It’s worth paying al ittle more to have someone else take care of the physical machines, and run things in virtual server that get moved to more and more powerful hardware over time.
I don’t understand any of the involved tech, but I understand that it makes our admin’s life easier. And I don’t think “we could just rent a server” is showing a good understanding of that. Maintaining these things up and running has a cost in person-hours, of which we don’t have a lot
Anyways, yes, “someone” can set this up in whatever way they want. Fix building on Haiku, cross compile it locally on their own non-Haiku machine, set up a build bot in the cloud or on a dedicated or virtual server, …
It won’t be me doing it. I’ve lost interest in keeping this alive, it’s too much time spent on it for something I don’t really use myself anymore. I will happily provide guidance and review patches, but I won’t be actively working on 32 bit support myself. It is demotivating for me, and I’d rather work on something else. I just figured out it is a better idea to admit that, be clear about it and write this message, so that everyone knows, and I can feel relieved about it.
I will of course continue doing the git merge, bugfixing where I can, and making new releases for the 64 bit version. That one I use daily and I can work on on my modern machine, not the old 32 bit install on my machine from 2014.
How would CI help? If the build is broken, then the build is broken, and that’s that.
What would be really nice is if HaikuPorter had better support for cross-compiling. We already have some of this set up with BUILD_REQUIRES vs BUILD_PREREQUIRES, but HaikuPorter itself isn’t cross-compilation-aware except in “bootstrapping” mode, I think. Then we could build 32-bit WebKit on 64-bit hosts easily.
Oh I’m pretty much aware of the maintenance costs involved. The company I work for is running a few servers to build the AOSP. While the dedicated server hosting includes the monitoring and free replacement of the defective hardware, other things (like setup, backup, sw upgrade) need to be done on our end (it’s also a single person doing it part-time, but of course there’s a difference between a paid job and a open source hobby project one do in their free time). We just calculated that setup is much cheaper for us compared to any of the cloud solutions (and we pay the person salary anyway). For Haiku / Haiku Inc. the calculation would be completely different one, and that’s understandable. Anyway, I just wanted to provide an option to consider. It’s okay if admin says it not viable one.
As far as I know, there is nothing special about bootstrapping in haikuporter. It’s just that: the setup needed for cross compiling. A few extra variables to tell which compiler to use, and a different set of packages for the host.
But that would also need a gcc that is set up for building 32 bit executables on a 64 bit system. Which the one built for buildtools does, but the one built for the gcc recipe in haikuports doesn’t. So maybe we should start with that.
There are two separate “backends” (BuildPlatforms), one for when packagefs is in use and one for when running on a non-Haiku host (like Linux). Last I checked, cross-compiling only works properly with the latter – you can’t run a bootstrap build on the packagefs BuildPlatform.
The reason you need cross-tools when building 32-bit Haiku on 64-bit Haiku is for the bootloader, which needs some special static libraries that the HaikuPorts recipe does not build. The recipe may already build the other kinds of 32-bit libgccs, not sure.
That makes for a strong argument to finally get 32bit run mode support included in the 64bit version of Haiku and march towards just one version of Haiku for R1 stable. Obviously not an easy task, but will certainly be a welcomed feature for those who want to run legacy BeOS apps.
Outside of needing R5 binary compatibility, how small is the number of systems that are SSE2+ (already needed for Webkit) and 32 bit only? Even my now 20 year old BeOS box is actually 64bit, though with 512MB RAM to keep R5 happy, 64 bit OSs would be a bit of a stretch!
I have no interest in 32 bit apps in general anymore. Honestly, I enjoy the simplicity of the 64 bit version, no more messing with setarch, ending up using the wrong compiler, etc. So I would rather not have that, and have R1 be 64 bit only.
(I know, some people will be unhappy about that. I understand it, but then it’s up to them to do the work to keep the 32 bit support working).
In my experience of building memory-intensive projects (e.g. Telegram), the consumption depends on the level of optimization - for example, to build Telegram for 32bit I had to lower the optimization from -O3 to -O2, and then to -O1.
My EeePC 701 already struggled to run WebPositive at all, so it’s not a big loss. But I hope Haiku as a whole continues to support 32-bit machines for a while longer. It would be a hassle to find any kind of replacement.
