It looks like the binutils pkg is also broken.
That fixed it. Thanks
My gcc2 repo has 1405 packages ATM. my x86_64 repo has 663. When you consider that about 300 packages are “any architecture” packages shared between the two (fonts, documentation etc), that tells you the difference between what is available for the two.
This is not just because I am crap at recompiling. I am, but that’s not the point. There are hundreds of applications for which the source simply has been lost. Those apps will NEVER run on x86_64. Until we see a major push of new user app development, we need them. We need them to point to when a newbie asks “what can I DO with Haiku?”
I agree that x86_64 is the future. But it is not the present. Ideally, we’d have a 32-bit subsytem on x86_64 the way OS/2 used to contain an entire Windows 3 installation. But that would be a big job.
Having such list would be valuable: one could start then to see if each binary-only applications have no alternative available and focus on them first. Depending on how much, the best way could be to have gcc2 32bits binary compatibility or to put efforts on alternatives that could become an acceptable replacement.
Not to mention HaikuArchives has had rather good success on reaching the authors of such apps and getting them to locate sources in their old backups and release them under a free software licence.
That does not sound like the ideal scenario to me at all. I would not want to incur technical debt just to run some old apps.
If the source or developer of the app is around then the app can be recompiled for x86_64. If neither the source nor the developer is reachable, then do we really need it anyways?
And this is not just a x86_64 issue. If we don’t have access to the source/developer that also means there is no way to make other changes such as bug fixes or adding new features. This also means that it can’t be updated for any post-R1 breaking changes (such as multi-user support or what have you).
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
- x86_gcc2 hybrid (gcc2 + gcc5) *
- x86 hybrid (gcc5 + gcc2)
- x86
- x86_64 *
- arm *
- powerpc *
- etc
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.
R1:
- 32-bit “Haiku gcc 2 hybrid + BeOS ABI compatible”
- 64-bit “Haiku gcc 5.x - No BeOS ABI compatibility”
R2 (speculative)
- 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)
1 Like
This will only happen if someone is actually interested in writing the code for doing it. There are indeed not that many apps affected, but here are some examples:
- Wonderbrush: closed source, the developer is still around, but has not much time to work on it and started work on a new version (Wonderbrush 2) which may or may not be released before R2
- GoBe productive: closed source, not actively developed, no good replacement available and more importantly no way to migrate documents to a more common format to import them into LibreOffice or some other modern office suite
- SynC Modular: closed source, author moved on to other projects and we have not been able to identify and contact him yet. A really great application and it would be sad to lose it.
- APlayer: open source, needs a lot of work to be fixed for 64-bit.
- Worms Armageddon beta: closed source, never officially released. Was already patched (by hacking the binary file) to get it running on Haiku.
These are just a few examples of apps which are going to stay 32bit for a while, and a few reasons why such things happen. We will eventually need to replace them, but they are still useful in order to provide a smooth transition (that means we can’t drop these apps until a replacement is available). The question is, wether we keep doing 32bit-only builds just for these, or try to get them to run in the 64-bit build, which takes more effort but would allow to get everyone to use the 64-bit version (not just now - I know some people still have 32bit only hardware).
Well, we will see what happens with R2. Since R2 will have pretty large ABI and API breakage anyways, it will need some kind of compatibility layer to run R1 apps in any case. And while we are doing that, it may not be that hard to also make it run BeOS apps.
My plans for R3 is that it would have ABI breakage again, a compatibility layer with R2, and drop support for R1/BeOS apps completely. But that’s very far in the future
There is Calligra Suite. If I understood right, it will be available in repo soon. So at least that one will be ok.
Read carefully
One of our devs has his tax files for the past 12 years or so all done in GoBe productive. Not only we need a replacement software, we also need a way to migrate the documents to the new format. As long as Calligra cannot open GoBe files, I don’t consider this problem solved.
I think there are translators to cover some cases, but do they work reliably?
1 Like
I was sure that GoBe does support MS Office files - there is info about that on Wikipedia Office Comparison. Oh well, I guess they took the later version, not available on BeOS. I never had occasion to work in BeOS and use GoBe.
@kallisti5 thanks for the detailed response, that is very insightful.
@General_Edmund_Duke GoBe Productive version 3 (the Windows version) could read/write Word files, I used it as my primary word processor for some time. I can’t remember about the BeOS version. Also, it only supported the old .doc format (not the new .docx). So you would really need to do 2 conversions. GoBe -> .doc -> .docx/other future file format.
While I’m not too worried about word processor files (in the worst case, you need to extract just the text and reformat everything - and you can make a pdf or paper copy for reference), I think it is possibly more difficult and risky to convert spreadsheets, especially if there are complex formulas inside.
Just in case that someone need it: I have the .doc and .xls translators from GoBe. With this (at least theorically) could export the files in that format.
If someone need it, send me a PM.
1 Like
could that be something to handle with translators, once someone’s got the inclination?
Any new updates on the ABI fix?
Looks like things are working for me so far (after an update). I do have a question for you… what is this “Software Updater” you spoke of in your last message in that thread?
It’s the relatively new GUI tool to update installed packages, including Haiku itself. It’s in Deskbar’s “Applications” menu. It does what in Terminal is “pkgman update”.
Thanks for the info!