gcc4

Haiku Finally Gets a Native GCC4 - full story inside!

News posted by umccullough on Sun, 2009-02-01 04:25
Michael's Quad-core compiling GCC4.3.3Michael's Quad-core compiling GCC4.3.3

As many Haiku community members know, one major hurdle that has been making it difficult to port new software to Haiku has been the lack of an up-to-date GCC4 compiler. While a GCC 4.1.2 cross-compiler has been available now for some time, cross-compiling software for a GCC4-built Haiku can be painful and frustrating. What Haiku really needed was a native GCC4 toolchain to run on a GCC4-built Haiku install.

That time is now! A native Haiku GCC4.3.3 is now a reality.

Michael Lotz set out to tackle this task and the fruits of his labor have finally been committed to the Haiku repository for all to benefit from.

Michael Lotz details the process he used

To demonstrate what process was necessary to perform this task, he has written a detailed blog post recounting his experience. It's a long read, and certainly lists some confusing concepts. If you were at all curious what it would take, going from a GCC2-built Haiku to a GCC4-built Haiku with its own native compiler, the steps are all there.

During the process, Michael was even "fortunate" to find and submit a patch for a bug in libiberty. You will read about the strange behavior that led to the discovery in his blog post.

Dogfooding is important... Yummy!

If you're paying attention while reading his blog, you'll note that Michael is "dogfooding" during his Haiku development. Not only does he use Haiku for development purposes, but it's also the only operating system he uses currently. This suggests a couple of important points: a) Haiku is stable enough to use daily and develop in and b) Haiku developers are serious about Haiku, intending to use it as their daily OS. I know of several developers who use Haiku daily for various tasks, including development. This demonstrates a dedication to the quality they are pursuing, and increases the likelihood that even little annoying things about Haiku are going to get fixed eventually.

What does all this mean? What's next?

Freshly-built Haiku running GCC4Freshly-built Haiku running GCC4

So, what should we expect from Haiku now that it has a native GCC4 toolchain?

I'm not sure - and that's the exciting part actually! This opens the door for easier porting of modern software, and more easily moves Haiku out of the "dark" GCC2 cloud that BeOS had lived under.

Several existing Haiku porting projects already require GCC4 to proceed and/or update to latest versions: Firefox 3, Webkit, VLC, and more.

Haiku already supports a "hybrid" environment where it is built with GCC2 for backward compatibility but also providing GCC4 libraries for future software support - or even more interesting: a GCC4-built Haiku with GCC2 libraries for backward compatibility. I think we'll see the latter becoming more common now with the availability of a native GCC4.

There are still some minor loose ends to tie up - such as providing the remaining development tools for a GCC4 Haiku (the GCC2-built ones will work, but they are not yet automatically installed with the "Development" optional package). Additionally, those who wish to build a GCC4 Haiku from within an existing GCC2-built Haiku might find it a little bit challenging. If you'd like to experiment, you may want to compile your own GCC4 Haiku from Linux, BSD, etc., or even wait for the availability of pre-built GCC4 images to appear.

These are very interesting developments, I hope you're as excited as I am at what the future holds :)

Steady Progress towards Alpha 1

News posted by stippi on Sun, 2008-05-18 11:27

This weekend, the Haiku project has seen some nice leaps forward. Two items are especially noteworthy: Ingo Weinhold and Axel Dörfler have finally nailed bug 2059. This bug specifically prevented serious use of Haiku for anything else than testing, since it meant that the kernel could crash at any time, especially when there was heavy disk activity. All that was supposed to be written to disk at the time of the crash was lost. Luckily, due to prior fixes to the file system journaling and log replay, it didn't mean that your entire file system would be corrupted, but at least anything that you were working on at the time would be lost. So the fix for this particular bug is getting us much closer to our goal of a usable self hosting situation in which you can actually use Haiku for development. This is our most important goal to reach before we wanted to release the first alpha of R1.

The second noteworthy achievement is build system support for a mixed GCC4/GCC2 Haiku environment. It has been known for quite some time, thanks to the explorations of Haiku developer Michael Lotz, that it was possible to set up a GCC4 build of Haiku to run GCC2 applications or vice versa, by installing the respective libraries into certain places so that the correct versions are used for linking. What was missing was support in the runtime loader (the system component used to launch applications and link them to the shared libraries that they use) to do this automatically and on a system wide level. Also missing was support in the build system to effortlessly produce such a hybrid Haiku build. Both of these items have now been implemented by Haiku developer Ingo Weinhold. Also related to this, Michael Lotz had researched the stability issues that GCC4 builds of Haiku were suffering from some time ago and tracked them down to a problem in the specific GCC4 version that Haiku is using. They can be avoided by simply turning off a certain compiler optimization feature. All this combined means Haiku can use GCC4 itself while maintaining our stated goal of binary compatibility to the large pool of GCC2 applications in an automated and transparent fashion.

A few serious issues remain before we can release the first alpha. Some concern missing or buggy functionality that affect the self hosting goal with regards to the development tool chain. A completely native port of Subversion is the last item on this list. As far as I know, some bugs in the TCP implementation are preventing it, but progress is being made on this front as you read this. Formal testing is being conducted to make sure the entire tool chain will work correctly and reliably. Axel Dörfler is currently working on the device manager, the system component which manages everything concerning hardware and drivers. There are some issues with regards to hardware interrupts that, when fixed, will hopefully clear up some driver problems that can be experienced on certain hardware.

I want to conclude with a big "Thank You" to everyone who is helping with tracking and reporting issues in our bug tracker and to everyone providing patches and of course to the Haiku developers themselves! Personally, I am very excited about the progress that is being made. Thanks to everyone who is contributing towards this goal!

Syndicate content