i am interested in Haiku. I want to convert one of my program on Haiku using vmware.
But my program needs GCC 4. I have read in a news (on haiku-os.org) that haiku will now be able to use programs compiled with GCC 4.
But i have read in a Mailing list archive that Haiku R1 will not support GCC 4.
When will Haiku be able to run programs compiled with GCC 4 ?
Is it hard to do ?
Windows and Linux can run program compiled with several compilers, why not Haiku ?
Your questions are better answered on the mailing list.
From what I understand. Haiku will be able to run both GCC 2&4 programs.
There is a good chance that R1 will be GCC 4 based when released. For now, they’ll be using GCC 2 to stay more compatible with BeOS ( to help make Haiku close to BeOS ). Then with late Beta or R1 they may switch to GCC 4 build ( my guess ) because GCC 2 is too outdated.
Basically, GCC 2 programs require GCC 2 libraries, GCC 4 programs require GCC 4 libraries. So, it means having a system with mixed set of the same libraries and the OS knowing which version of the libraries to use.
A GCC 4 Haiku will run GCC 4 programs. A GCC 2 Haiku, with GCC 4 libraries for the GCC 4 program, should also work too.
What date was the post saying R1 would be GCC 2 based? If it is before June 2008 then I wouldn’t pay much attention to it, because that position may actually change the closer Haiku gets to releasing R1.
Apparently I’m still not getting new post notifications from Drupal… strange.
Anyhow, if your program is C only (not C++) you should be able to compile it with GCC4 and run it on a GCC2 version of Haiku. The compatibility problem occurs when compiling C++ apps that link to core OS libraries because the ABI changed between GCC2 and GCC3 causing the binaries to be built differently. This prevents a GCC3+ app from linking to a GCC2 binary and vice-versa.
Linux would have this problem as well, but few core libraries on Linux use C++ in the first place, and most everyone uses GCC4 now on Linux anyhow, so nobody notices.
So a GCC2+4 version of Haiku will require libraries compiled with both compilers to be present on the system, and the runtime_loader is intelligent enough to detect which compiler a binary was compiled with and load the appropriate libraries for it to link to. Thus, you’ll end up with double the libraries in order to support both compilers. This obviously is a less-desirable approach, and will only be used for transition between compilers.
What date was the post saying R1 would be GCC 2 based?
17 Jun 2008:
My program use C++ with anonymous union, and other things which do not seems to be supported by GCC 2.x (i think).
I am interested in Haiku but i do not have the time to build it, conect to svn, …
A vmware image is quick and easy to use.
It’s sad to read that Haiku do not support GCC 4 today. A lot of other programs will not be able to be ported to Haiku.
I think i will have to wait several months/years before starting to port my program
I believe gcc2 does in fact support unnamed unions, as there are some used in the Haiku code already.
[quote]It’s sad to read that Haiku do not support GCC 4 today. A lot of other programs will not be able to be ported to Haiku.
I think i will have to wait several months/years before starting to port my program :([/quote]
As tonestone57 suggested, Haiku does support gcc4 today. It’s not as stable as a gcc2 version, and the advantage of using gcc4 isn’t great at the moment.
You can pretty easily build it yourself from a Linux machine in ~1 hour (at least, that’s about how long it takes me to download all the sources, compile the cross-compiler, and compile a Haiku image on my core 2 duo Ubuntu box).
After that, updating the image daily usually just takes a few minutes to grab the update sources (svn up), and recompile the targets that changed. You can even incorporate your app into the build process to be built and installed on the image automatically.
But anyhow, that’s my opinion. As a developer, I would have thought you’d like to go this route anyway.
True Greg. Today Haiku R1 is meant to be GCC2 but as time goes on this is very likely to change. Many 3rd party ( and even Haiku ) developers will put pressure to have GCC4 Haiku for R1 - you’ll notice this more once Haiku gets to BETA. Otherwise it’ll be tough to port over newer software to Haiku.
There are two main reasons for using GCC 2. 1) To remove one extra variable, GCC - so Haiku stays very compatible to BeOS 2) To allow BeOS GCC 2 programs to work on Haiku.
The first reason won’t matter the closer Haiku gets to R1 since it’ll become very close to BeOS.
The second reason won’t matter if Haiku becomes a hybrid system ( able to run GCC 2&4 programs ). This is what they’re aiming for and then there won’t be any compelling reasons to use GCC 2 any longer.
This is why I say that as time goes on that Haiku R1 could be GCC4 compiled ( rather than GCC2 ) but no one can say for sure - time will tell. And you’re right, you’ll have to wait years ( months if very lucky ) for GCC4 Haiku to become readily available ( by image ).
Only 2 options are available to you today. Either you download source, build cross compiler and build GCC4 Haiku + developer tools yourself or you have someone else do it for you ( cough, Urias, cough, cough ). Still, I really think it better to wait for Haiku to reach BETA before porting over GCC4 programs because GCC4 should be more stable with Haiku BETA and maybe easier to do ( will probably be easier to get GCC4 image ) and should have fewer bugs to deal with.
I wouldn’t be adverse to putting together an image or two on occasion for others to test gcc4 bulds of Haiku.
The biggest problem actually would be the lack of a native gcc4 compiler for Haiku yet - so even if I made a gcc4-based Haiku image, you couldn’t actually use it to develop gcc4 Haiku apps. For that, you’d have to use the host build environment (i.e. Linux) to cross-compile your apps and put them on the image at build time anyway.
There is a binary gcc4 cross-compiler that mlotz hacked together for R5 BONE in order to build a gcc4 Haiku from BeOS/Zeta, but I’m not sure how easily it could be used in Haiku itself.
If I were considering porting a small app to Haiku today (which I actually have done) - I’d start by trying to fix the code so that it compiles on gcc2 as much as possible, and if you absolutely hit a wall, I’d cross-compile it from Linux using gcc4. If it’s C++ and links to Haiku’s libs, you’ll likely be unable to run it on Haiku without the gcc4 libraries also, but as tonestone57 suggested, I think that will become a moot point as Haiku gets closer to Beta. Currently the webkit port requires gcc4, as does Firefox 3 - so if anyone’s planning on using a modern browser in the future, I think gcc4-built libraries on Haiku are going to be a requirement anyway.
What’s this I hear about GCC 2.9x supporting anonymous unions? My game engine is forced to use #ifdefBEOS in all instances where I encounter anonymous unions. I’d love to get rid of that code, since that is the only conditional code I have in the entire engine. Everything else works just beautifully with Haiku, (even OpenGL 2.1, OpenAL etc).
For those of you who don’t know what an anonymous union is, look at the following code:
}; // error under gcc 2.9x, fine with newer versions.
Tuple var1, var2;
var1.x = 20; // error under gcc 2.9x
var1 = 23; // ok
Excuse my ignorance on this topic since I’m not much of a C/C++ developer…
There was a recent issue that Axel fixed in the ext2 code where an unnamed union was causing problems with gcc4 and not gcc2 (opposite issue I guess), but it was inside a C struct, which I guess is a different usage entirely?
The post about R1 not being GCC4-based was a recent one from mmu_man. When I finally catch up on all the Haiku mailing lists, I’m planning to bring this issue up there.
I believe Axel is the most keen on sticking with GCC 2 for R1. That’s because there’s a raft of new APIs planned to be included in R2, which will break binary compatibility. His opinion is that this is the point when it makes most sense to switch to GCC4. If we do the switch earlier, R2 would need 3 sets of libraries - GCC2 compat libraries, GCC4-R1 compat libraries, new GCC4 native libraries. By keeping GCC 4 as an option and not the default it seems less bad to drop GCC 4 R1 binary-compatibility.
This is Axel’s position as far as I understand it. I don’t necessarily agree with him - I think we could have an R1 based on GCC4 but make it clear the binaries will not be compatible in future Haiku until the APIs have settled. I think it would be worth it to combat the feeling of new interested developers such as greg2 that Haiku is outdated as soon as it is released. Having a “GCC4” option as a second-class citizen does not go far enough IMHO.
Maybe it would be better to use GCC4 only for R1 and to use GCC4 64 bits for R2 (with an emulator for old beOs applications on R1 and R2)
R2 will not be available before a long time. 64 bits will be available on all machines. People which will download R1 32 bits, will be surprised by the break of compatibility with R2 32 bits several months later, and with break of compatibility with R3? 64 bits several months later again.
As a new user of Haiku. This is my opinion:
I don’t need BeOs compatibility because i am not a BeOs user and BeOs is dead, and its old programs are … too old.
But i understand that some user of Haiku are fan of BeOs (and maybe BeOs compatibility is needed for other reasons).
Using GCC2 or GCC4 does not matter for end users, like myself.
But new developers won’t want to make their code compliant with GCC2. Already two people, greg2 & Zenja, would prefer GCC4 for their programs. Many other developers will feel the same way too.
Axel makes a very good point. I didn’t even know they were doing new APIs for R2. I wouldn’t want 3 sets of libraries either - messy. But it’s true that if you tell people the APIs are going to change with R2 they can update their programs accordingly. ( and NOT include any GCC4-R1 libs in R2 - make this very clear to the developers ). And if these developers enjoy and continue to use Haiku then I’m sure they’ll make their programs R2 compatible. The only developers we’d lose out from are the ones that decide to leave Haiku before R2 - would be very few lost developers/programs - not a big deal.
I don’t think many developers will be happy using GCC2 for R1. And some ( or most? ) may just end up waiting for GCC4 R2. Another thing to keep in mind is that GCC4 R1 will attract more developers overall.
If Haiku R1 is GCC2 then either someone ( or a group of people ) will just have to make a well done GCC4 Haiku distro with developer tools. Better to get new developers on-board from R1 rather than R2.
I agree to the majority above that R1 should definitely already support gcc4 in one way or other. Most developers of today, as well as the vast majority of the potential future users of Haiku, have no interest at all in BeOS compatibility. However, all of them want to develop and use new software that is based on new APIs. Take the (very basic and essential) Boost libaries as an example… many won’t work with gcc2.
In my opinion it’s no problem at all to break R1-gcc4 compatibility in R2, as long as everyone is informed in the earliest stage.
Of course BeOS compatibility is a good thing and should definitely be present, but it shouldn’t prevent Haiku from attracting developers and users. I think the renaissance of a modern OS with the qualities of BeOS is a more important goal than being able to use old BeOS apps.
I’ll be happy when i can use the Boost libraries on Haiku as i can use them on other platforms, remember that!
Maybe it could be a good idea to not release Haiku under the name “Haiku R1” but something like “Haiku Developer Edition”. Just to attract developper for R2, and to say to people: “Warning: This is just the step one before a revolution”
Because Haiku R1 seems to be just a prototype. People (general public) want a good and modern opertaing system, not an emulator for an old operting sysytem from the previous century.
Haiku should not be handicaped by old compatibility. Microsoft Windows have this problem. It must be compatible with old programs (DOS, Windows 95, 2000,XT,Vista,…).
Apple do not have this problem their new operting system are … new.
R1 have to support GCC4 because it will allow to create new program (with source code), which could be adpated to R2 in the future. GCC2 is only usefull for program we do not have the source code. But how many peopl will use this old program ? Why ? Just for fun ? and is it wise ? (bugs which cannot be fixed, security, …).
GCC4 will allow to port or create thousands of new program. GCC2 is only able to run ten programs.
Haiku R1 sould be GCC4 only with an emulator or a system similar to Wine to ba able to run old BeOs programs. It’s just my point of view but i will probably never install Haiku if it only support GCC 2.