Has Haiku abandoned BeOS compatibility?

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.

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.

Now you've got it. :)
You need a hybrid image to run programs compiled with gcc2.95 as well as those that need gcc4.

I use a gcc4 image with additional 2.95 libs, but vice versa should work the same. Never tried though.