[Libreoffice] postresql-sdbc bits out of minutes of tech. steering call
Lionel Elie Mamane
lionel at mamane.lu
Thu Dec 8 09:45:30 PST 2011
On Thu, Dec 08, 2011 at 04:19:04PM +0000, Michael Meeks wrote:
> * postgresql fun. non-internal
> + postgresql have a strict API stability (Norbert)
Norbert was saying they have a strict *ABI* stability, properly
managing sonames and all that. I'm not sure if MS Windows has a
mechanism that gives the same functionality of "marking
ABI-incompatible versions as such", but
http://en.wikipedia.org/wiki/DLL_Hell suggests they do not. In this
case, we absolutely cannot rely on the users installing libpq
separately, beyond the problems mentioned by Fridrich.
> + Windows - run-time DLL dependency a pain (Lionel)
> + ship DLL ourselves ?
This is not a question mark, we have to do that, or link statically,
be it only because of Fridrich-mentioned problems.
Note that currently postgresql-sdbc always links statically when using
internal PostgreSQL. It links dynamically with system PostgreSQL, and
does not ship the dynamic library itself. The latter is typically what
GNU/Linux distributions want: the package will have a dependency on
the right dynamic library. Is that what we want for our downloads from
http://www.libreoffice.org/download/ ? Maybe not, I notice that the
.deb files we distribute declare no other dependency than between
> + building vs. an internal libpostgresql (Lionel)
> + client library code is:
> + around 25 files + a few headers
> + can knock up a gnumake makefile in a module
> as a static library.
So, the situation with Windows is a bit more flexible than what I
previously reported, but that is not necessarily helpful to
us. PostgreSQL on Windows can be built in more ways than I knew:
- ActiveState Perl and MSVC: no go, we'd like not to require
ActiveState Perl as a build dependency
- MinGW: would requiring MinGW/MSYS as a build dependency be any
better than requiring ActiveState Perl? I understand this
build does not need any piece MinGW/MSYS at run-time (like
Cygwin would), and I guess it is binary-compatible with
MSVC-compiled code? I mean we compile only libpq with MinGW,
the rest of LibO with cygwin-bash/awk/... driving MSVC and
it all works out?
- Cygwin: Tor explained this is not useful
- Borland C++ / old MSVC: not useful
- knock up our own Makefile for the subpart we need: more fragile wrt
to new versions of PostgreSQL (may need to update that makefile);
but possibly still the easiest solution.
More information about the LibreOffice