[haiku-development] Re: GCC 2.95 and certain #define macros
- From: "Ryan Leavengood" <leavengood@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 20 Aug 2007 21:12:29 -0400
On 8/20/07, Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
>
> I don't think it's impossible, and we've actually talked about the
> possibility already. We just didn't consider it urgent. It was thought of
> more as a post R1 solution, when we would migrate to gcc 4, but still try
> to be binary compatible.
Yeah that was my understanding as well. But having a fast native
browser would really improve Haiku's usability and elevate it out of
being just a "hobby OS" that people play with for 10 minutes before
rebooting. Though maybe Firefox could get us by for a while. Obviously
I have some bias though since I clearly want WebKit on Haiku ;)
> Anyway, I would advise you not to do that ATM. This is not just a small
> change to the runtime loader. If you want to run a gcc 4 executable, you'll
> obviously need gcc 4 versions of the libraries (libbe,...). Those
> communicate with servers (app/input server, registrar,...) and might even
> share source code with them. Those servers in turn have add-ons. In the end
> you'll probably have to invest quite a bit of work to actually get a hybrid
> Haiku installation going.
Yeah I don't think it is trivial, but certainly doable. Since the
servers are implemented as they are and only have a BMessage interface
to the rest of the system I don't see the dependencies. Add-ons are
certainly a problem though, and I would suggest that components which
might need to be used with older BeOS add-ons (screen savers maybe)
would be GCC 2.95.3 compiled. But I would think the registrar,
input_server, app_server, midi_server, media_server, and debug_server
could all be safely GCC 4.x. But time and testing will tell.
Of course we could always have everything default to GCC 2.95.3 for R1
and have the special case be 4.x apps. Later that can be reversed.
> I believe you're better off to just to port everything to gcc 4 Haiku,
> first. This will likely give you less porting problems (though gcc 4 Haiku
> might not work as well as the version compiled with 2.95.3).
That is the plan. Any idea how a GCC 4 Haiku would not work as well?
Are there definite things to look for or parts you know are broken?
I'd be willing to fix anything major since I'll want a fairly stable
Haiku to test on :)
FYI I have been using it for a while but don't know if the bugs I've
seen are GCC 4 specific or just "normal" bugs, hehe. I'm going to have
to test both I suppose.
> When the port
> gets usable, you can start considering what to do about the gcc 2.95.3
> issue. Maybe Haiku R1 will already exist at the point and the migration
> path to gcc 4 would be much clearer.
Though I've certainly had some troubles lately, I plan to have the
port in decent shape within a few months. I'm not sure what time line
you were thinking, but I doubt Haiku R1 will exist in that time. This
is why I've brought up this issue now, as a quite a few Haiku
community members may want to run my WebKit browser but won't be able
to on the default Haiku if I can't get WebKit compiled with 2.95.3.
Even if the browser is buggy as heck I'd like for other people to test
it at least.
Thanks for the response though, I was waiting for your input on this issue :D
Ryan
Other related posts:
