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 themselves. > + 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 http://www.postgresql.org/docs/9.1/static/install-windows-full.html - 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? http://www.postgresql.org/docs/9.1/static/installation-platform-notes.html#INSTALLATION-NOTES-MINGW - 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. -- Lionel _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
