It seems to me that the question on how the problem of different GCC versions should be approached in the future has been discussed somewhat. I thought that we ought to open a new forum or debate-style webpage where users and developers alike can come and share their thoughts and see if there’s a way that we can have just one version of Haiku running all the available apps. Whilst what the developers have already done to get hybrid versions working is great, I think that many users seem to be a bit confused about why they have to choose a version. In the past many computing problems like local IP addresses and hard disks too large for the int 13h BIOS have been solved by a bit of lateral thinking and jiggery pokery, so let’s see if there are any clever ideas on how we can make the subject of GCC confusion a bit easier in the long run. If you have any thughts on this proposal, please do share them.
Well the Haiku developers have made it pretty clear that Haiku Release One will be a gcc2 Hybrid and Release Two and onwards will use gcc4.
This is needed to bridge the large gap between gcc2 and 4.
This teething inconvenience can not be negated.
I’ve seen quite a few comments from users that say that it seems pointless to have made an OS that’s compatible with BeOS to then drop this after it’s first release, and I have to say that I agree with them. If the role of open source software is that the end users have a say in how it’s created, and that it is flexible, then can it harm to have a discussion about whether there are alternative options? Surely there must be some way to put a compatibility layer in somewhere, like a Tracker GCC2. This kind of thing has been done before. In fact, through Wine, cygwin, and other similar developments, it’s possible to run programs from a completely different OS on the host machine.
Out of interest, could someone please explain to me what happens on, for example, a GCC2H system when a GCC2 and a GCC4 app are launched?
Seems like people saying this are misinformed (or I am and don’t remember it correctly… :)). AFAIK, R2 will only break compatibility with currently gcc4 compiled apps because of major API changes. gcc4 (or whatever compiler is then current) will become the default for R2, but old R1-compatible gcc2 libraries will be shipped alongside, so old BeOS apps are still supported. IF there’s still demand for that at that time, of course…
Regards,
Humdinger
I know I am misinformed, and this is because I haven’t read any official discussion on this issue. It may have been discussed on one of the developer mailing lists but I think something important like this should be “officially” written up, posted to haiku-os.org, and discussed.
Including GCC 2.9 libraries is necessary for maintaining compatibility with ALL legacy BeOS applications. But GCC 2.9 is old and not suitable for developing new applications. So having a GCC2 / GCC4 hybrid allows both backwards and forwards compatibility. I am not sure what the downside is of carrying forward the GCC2 / GCC4 hybrid. Maybe someone else can comment.
I am not an expert but this is my understanding. And I think that maintaining compatibility with many dozens of really useful applications is important. As we add new developers and recode everything that will change. But that is in the future.
I fully agree with trying to keep BeOS applications compatible. But I am not convinced that the current way of handling this is the right way to go. Why don’t we stick to a GCC4 version, and release a BeOS compatibility package with GCC2 libs and some tweaks? Since developers are likely aware of the fact that future Haiku versions won’t be binary compatible with older GCC4 versions, those who develop with GCC4 will probably make sure to update their applications so that they stay usable. The compatibility layer would deal with legacy stuff that won’t change.
If we stay on the current path, it will get even more confusing if we throw Clang and different CPU architectures into the mix.
I’m no expert on this issue either. I now dug up a two year old thread where this stuff was discussed. A kinda summary is post 34, but you should probably read it all if you find the time. 
Feel free to condense it to a FAQ-answer and post it to the mailing list so it can be added.
Regards,
Humdinger