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 _______________________________________________ LibreOffice mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice
