Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


On Mon, Aug 15, 2016 at 08:57:04AM +0200, Noel Grandin wrote:

Just a random thought - it seems like linking firebird into LO is a
lot of pain.

Is there any real downside to just building firebird as an
executable and then running it as a sub-process of LO?

We still need to link to the client library. So (by our current
policy) we still need to compile it as an external, and with Firebird
3, the client library is the same as the "embedded server" library,
they have been folded into one.

True, when being used as a client library, it does not dlopen() other
libraries... And these dlopen() are the source of our difficulties
now...

It just seems to me that we're running "against the grain" here

Well, looking at it in one way, not by official Firebird mission
statement. It is supposed to be embeddable. Where we possibly "run
against the grain" is by insisting on shipping it as part of
LibreOffice, in the LibreOffice directory tree arrangement, and
shoehorning it into our build system. If we would use a
system-installed one, the problems we are having would disappear, but
I think we would be opening another can of worms:

 * version management and data format compatibility
 * on non-Unix-or-GNU/Linux architectures, where to find the
   "system-installed one"?

-- 
Lionel

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.