[haiku-appserver] Re: Linkage Mess

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 12 Jul 2005 18:07:09 +0200 CEST

Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > FWIW, libopenbeos.so links against libbe.so as well - we would need 
> > to
> > change that as well...
> Ah, I didn't even think this one is still there. I haven't tested it 
> yet, 
> but if our kits are complete enough, we should be able to just remove 
> it. 
> libbe code that needs to be accessed for any reason should be made 
> available through libbeadapter.

Indeed, I guess one should have the unit test run (compiling them 
should be enough, though) in this case to find out about any problems?

> > AFAIK only the BApplication and ViewInterface stuff relies on the 
> > test
> > platform. Any other things?
> > How hard would it be to put them into an add-on?
> Not that hard, I hope. What has to be taken care of is that objects 
> may 
> cross implementations by passing them through the interface. E.g. a 
> BRegion 
> passed to the add-on may have been created with the libopenbeos code 
> and 
> will be used by the libbe code.

That's exactly what I was thinking about. I don't have a good idea for 
that, though. It would certainly help to find out if we pass any of 
these regions to a libbe.so API.

> > For a start, a shared library could help as well, BTW, and would be
> > much simpler to do, although it wouldn't guarantee us that we're 
> > free
> > of host dependencies.
> Why not? There should be little difference between a library and an 
> add-on, 
> save that a library will be easier to use. Or do I miss something?

Yes, I think you're right, they should be equivalent. I thought that if 
the app_server links against lib X that links against libbe.so, that 
one would already bind the symbols needed from libbe.so, but IIRC this 
is not the case.


Other related posts: