The reason I ask is because, in the GCC4 version of Haiku, I can’t use Firefox (it won’t start) and Circus Linux won’t run either. As so much has changed (such as: no more /beos folder (now called /system) and a lot of stuff is in /common now, etc.), it makes me wonder just how much BeOS software will still even work! I assume the GCC2 version of Haiku has the name folder changes and such.
It appears, from what I’ve seen, the GCC4 version of Haiku is gaining more and more prominence. Is this to be the new path Haiku is taking? If, so, great (I’m all for anti-legacy and forward-thinking and all whatnot)… but I think we need to have people rewriting programs so they’ll work in Haiku again…
In the latest GCC4 build I created (r31495, I believe), I have tried a bunch of games and various tactics to make them work. Nothing worked. Files can’t be found and games/apps won’t run. At this point, I’m wondering if HaikuWare needs to dump it’s current repository, as I’m not sure if ANY of the software there will work on Haiku today, without recompiling. That means everything there is unusable to any Haiku user today, because of changes made.
If recompiling is the necessary route in order to make what used to work, work again, I think it would be wise to start ASAP. As long as the changes to the directory structure (and/or whatever else has broken BeOS R5 software compatibility) aren’t going to be changing too much more from here on out, then I think a concerted effort should be undertaken to get apps recompiled so Haiku has usable apps once again. Naturally, those same apps will probably not be BeOS compatible any longer, but HaikuWare is for Haiku software, not BeOS. The cross-compatibility was simply a convenience, but methinks that’s gotten seriously broken somewhere.
Is the GCC2 build of Haiku in the same software predicament, or is this whole thing less to do with directory structure and all to do with which version of GCC is being used? We gotta start getting things figured out, so these kinda things don’t happen and frustrate end-users.
[quote=mmadia]A pure GCC4 version of Haiku is not binary compatible with BeOS. This is due simply to the developers of GCC not caring about backwards compatibility.
However, Haiku supports running as a GCC Hybrid, which retains binary compatibility with BeOS. There are two possible hybrids: X86 GCC 2.95 Hybrid and X86 GCC 4.x Hybrid. The “GCC --” indicates which version Haiku was compiled with. The “Hybrid” refers to a set of alternative libraries, translators, etc.[/quote]
Oh, wait a sec… you mean that NO BeOS software will work in pure GCC4 (i.e. non-hybrid) builds of Haiku, regardless of what you do? If that’s the case, then my apologies for my misunderstanding. I was under the impression that GCC4 Haiku built apps, etc. wouldn’t run in BeOS, but that BeOS software would still run in GCC4 Haiku. But it goes both ways, eh? GCC4 Haiku can’t run BeOS software and BeOS can’t run GCC4 Haiku apps.
So, then, if I want ANYTHING to run in GCC4 Haiku… I better get to recompiling 'em, eh?
A pure GCC4 version of Haiku is not binary compatible with BeOS. This is due simply to the developers of GCC not caring about backwards compatibility.
However, Haiku supports running as a GCC Hybrid, which retains binary compatibility with BeOS. There are two possible hybrids: X86 GCC 2.95 Hybrid and X86 GCC 4.x Hybrid. The “GCC --” indicates which version Haiku was compiled with. The “Hybrid” refers to a set of alternative libraries, translators, etc.
[quote=darkwyrm]As it is, the BeZillaBrowser is just Firefox without the branding.
The newer compiler is necessary for work down the road, though. CLucene, the base for the desktop search project that Ankur Sethi is working on, needs the new compiler. So do Firefox 3 and Ryan Leavengood’s Webkit browser project.[/quote]
The BeZilla builds are actual Haiku binaries. The also include numerous patches that aren’t in Mozilla’s codebase – particularly tqh’s new NSPR (NetScape Portable Runtime), which basically is the glue that binds Mozilla together. There a few other patches as well. Basically, if you’re running Haiku you should be using the BeZilla builds. There’s a closed ticket on Trac that even includes links for MailNews (Thunderbird), Calendar (Sunbird), and Suite(Seamonkey).
IIRC, the issue with Firefox 3 isn’t gcc4, but rather a port of Cairo that passes all of the tests. There’s been a few people claiming that Cairo has been ported. Those attempts contain non-functional stubbed out code, which allows it only to compile and not function properly.
One more point - you don’t really have to rewrite programs to run them in GCC4 Haiku - you basically just recompile them. This is not Haiku’s fault, it is GCC’s.
Almost. GCC4 is stricter about certain language constructs. Sometimes code that compiles just fine for GCC2 needs a little tweaking to compile under GCC4, but nothing major is required.
The hybrid builds will run the Firefox available on BeBits. As it is, the BeZillaBrowser is just Firefox without the branding. A purely GCC4 build is kind of a pain in the neck, but the GCC2 and hybrid builds run stuff from BeBits and Haikuware without a hitch.
The filesystem changes took me by surprise, too, but they really aren’t a problem. In R5, there is a function called find_directory() which asks the system for the location of a particular kind of folder. For example, find_directory(B_BEOS_DIRECTORY) on R5 gives /boot/beos, but on Haiku, it should return /boot/system. Everything in the /boot/common folder is supported under R5, too. It just wasn’t put into place in R5 or Zeta.
The break in compatibility between the two compiler versions, as was mentioned above, was actually the result of changes made by the guys responsible for GCC compiler itself. If I understand things correctly, the compatibility breakage only applies to code written in C++, so C-based libraries compiled for GCC2, for example, will drop into place and work just fine.
The newer compiler is necessary for work down the road, though. CLucene, the base for the desktop search project that Ankur Sethi is working on, needs the new compiler. So do Firefox 3 and Ryan Leavengood’s Webkit browser project.
No blame attaches to the GCC team. Stroustrup’s C++ language is/ was under-specified. The GCC authors had two equally unpalatable choices, either implement some arbitrary flavour of C++ from say 1995 and then stick to that no matter what happened with language standardisation, or else repeatedly break compatibility.
The most egregious ABI problem was the name-mangling. The linker works by taking many references to the same symbol and merging them. To do this it must be able to uniquely identify each symbol. In C this is easy, each symbol has a unique name. In C++ many symbols can share the same name and are made unique by context such as the types of the parameters to a method. Thus the compiler needs a “name mangling” strategy which reflects low level language decisions by assigning each such symbol a unique string which reflects only the relevant contextual information. Any change to these decisions (and there were many) requires changes to the name mangling, which in turn means compiled objects are no longer compatible.
You might reasonably blame Stroustrup (for the lack of a defined ABI) or those who popularised C++, or Be Inc. for choosing it as the system language for BeOS, but the GCC developers just did their best with what was available.
Be Inc. at the time asserted that the problem with C++ was unimportant, because they felt that compatibility was over-rated, JLG’s big idea was you should break older software in order to avoid accumulating “cruft”. This is quite a contrast to the situation today where Haiku is implementing APIs that have been deep frozen for almost a decade.
From day #1, Haiku developers stated that the primary reason they wanted to keep binary compatibility for R1 was to focus the developers on a common goal. Otherwise, everyone would be out doing their own thing (this is a volunteer effort after all), and we’d never have a final product. Ever. In retrospect, this was a brilliant strategy, when compared to what happened to all the other BeOS inspired projects from 6-7 years ago which got nowhere fast.
With R2, the developers will revisit and change the API, which obviously means that we’ll lose the “cruft” sooner than most people think.
“keep[ing] binary compatibility for R1 was to focus the developers on a common goal. Otherwise, everyone would be out doing their own thing (this is a volunteer effort after all), and we’d never have a final product.”
We kept largly to R5 and binary compatibility, so everyone didn’t went out doing their thing.
Therefore we still don’t know if his concern that this would take place, would’ve come true if we didn’t stick to R5 compatibility.
When was the Haiku (formerly “Open BeOS”) project started? 2000? 2001? In either case, this project has been in pre-Alpha/Alpha status for between 16-17 years. Is that really normal for an open-source project that is truly “focused”? Did Linux or BSD take that long to become acceptably mature (or what might be considered “version 1.0”)? And, when Haiku reaches Beta… how many more years will it remain at THAT level? Yes, I think it’s a valid concern… unfortunately.
Haiku hasn’t been in Alpha stage since its inception as OpenBeOS.
But I get it, it’s been taking a long time. What else is new?
I don’t want to spend more time on this, but re-read Zenja’s concern. It’s basically," if we don’t aim for R5 feature equality as a goal, people will fork their own projects." If we didn’t heed Zenja’s advice, there may have never been an Alpha or Beta.
Haiku is every bit MORE than BeOS R5 ever was, feature-wise. But the technology mark keeps moving, so the race goes on… and on. Stop running after endless technology improvements. Finish the “race” of making Haiku R5-equivalent and THEN start a NEW race. Any reason why that can’t be done?
Maybe you haven’t noticed, but that is exactly what’s happening right now in Haiku? I guess R1 will finish the “BeOS R5 race” and devs will focus more on new features for R2…
I created a Beos folder and copied all the sub-folders into it and managed to get the old Be Developer ide started. It seems crazy to me that an operating system, so beautiful and simple, should be barstadised with a name change to break everything, and then to top it off, complicate the lovely simple install with a flavour of linux complexity.
After I discovered that, I stopped all development work until something is presented fully documented and tested, like the original BeOs tools were, and should still work no problem, yet dont.
