[haiku-development] Re: GCC 2.95 and certain #define macros

  • From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 21 Aug 2007 14:22:30 +0200

On 2007-08-21 at 03:12:29 [+0200], Ryan Leavengood <leavengood@xxxxxxxxx> 
wrote:
> On 8/20/07, Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
[...]
> > 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.

Yes, it's mostly BMessages. The app server uses shared memory too, though, I 
think, ATM it's used only for bitmap data (that might change though). 
BMessages can contain structures, and I guess we've at least to make sure 
everything goes well with those (pure C code should mostly be unaffected, but 
not completely).

> 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)

Well, screen savers would certainly be the last things I'd not switch to gcc 
4 for. :-)

> 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.

We'll have to see how much work that is. I'm particularly thinking of how the 
build system shall support building a hybrid Haiku image.

> > 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 :)

There was a kernel problem that has already been fixed (gcc 4 optimizing a 
bit more than was good for us). I believe ATM no other particular problem is 
known, but the gcc 4 build is by far not as extensively tested as the gcc 
2.95.3 build.

> 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.

Yep. It is also not unlikely that gcc 4 exposes different (common) bugs due 
to different stack usage and optimizations. We've already squashed a few that 
seemed gcc 4 specific at first, but were actually just not as visible with 
the gcc 2.95.3 build.

> > 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.

I hope that in a few months we'll have at least an alpha release, and maybe 
there'll be less on the plates of those who are already intimate with the 
runtime loader and related code to help with creating a hybrid Haiku image.

CU, Ingo

Other related posts: