[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.
Bye,
Axel.
Other related posts:
