On 12/12/11 08:14, Lionel Elie Mamane wrote: > I did that because it seemed the easiest thing to do at first > sight. However, we are losing the advantage of that, and thus I > propose we switch to dynamic linking, and bundling the lib on > platforms / situations that need it.
Where are we actually losing the advantage? The way I quickly hacked the internal postgresql for windows was a proof of concept and surely we can extend it. > - no SSL/TLS support, for encrypted communication with the DB server > and authentication by X.509 certificate. We bundle OpenSSL with LibreOffice, so should be possible to build it against the internal or system OpenSSL according how the build is configured. > - no Kerberos support: authentication; apparently can be used for > windows domain "single signon" from a non-windows machine. So, this should not be a problem for windows then. Should it? > - no GSSAPI support: yet another authentication mechanism > > - no LDAP support: yes, in the client library: this allows to store > the connection info in LDAP and thus manage it centrally. Can be > really convenient in enterprise environment. > > I started hacking our internal postgresql to activate all this, but > this introduces dependencies on yet other libraries: OpenSSL, MIT > Kerberos, com_err, ldap, ... This means that linking statically > against libpq is not the easiest anymore, since static linking does > not automatically recurse, in the way that dynamic linking does :) Yes, but this is feasible, since the stuff will be linked only in connectivity/source/drivers/postgresql, so having the dll linking in postgresql with all those libraries, or having the uno component linking against static libpq and all those libraries in connectivity is the same work. > So, to me it looks like we'll switch to dynamic linking against libpq > and shipping the DLL/SO/DYLIB on the platforms/cases that need it. Any > platform where this will be harder than what I presume? It will not solve anything unless you want to use a shared library from somewhere else. You will still have to build the shared library with all the support and link it with the external libraries. Moreover, it might actually introduce a problem when your internal shared library of a certain name could be a bit different then the system one of the same name. Been there, done that. Not really a good solution. > As an added bonus, this makes it easier for our users to upgrade the > libraries we link against (for bugfixes or new features in new > versions or ...): just overwrite the DLL/SO/DYLIB file with an > upstream-provided one (downloaded from http://www.postgresql.org). No, no, no! Then you will have a mix of environment that you don't know compiled with options that you cannot be sure about and you will have an unmaintainable code. > This also means that by our "we have to build everything we ship" > rule, we have to internalise, according to my first quick survey: > > - OpenSSL: I expect all platforms. It is a system lib on most > GNU/Linux distributions, but the soname is not stable. We ship it already, so no problem there. > - MIT Kerberos: > > * MacOS X bundles Kerberos since 10.2, which AFAIK is behind our > baseline of 10.4; is it binary-compatible across releases? Then > we can consider it a system library on MacOS X and not > internalise / ship it. > > * GNU/Linux: What's our baseline there? Has the soname changed > since our baseline? Is the soname consistent across > distributions? If no&yes, then system lib and don't ship it. > Debian seems to have a stable soname since woody (released 19 > July 2002), so I expect this will be OK. > > If we have to internalise it, it depends on: > > ° libcom_err: built from e2fsprogs sources on my Debian, soname > libcom_err.so.2. Google tells me (some?) RPM > distributions have a libcom_err.so.3 that is > shipped by the MIT Kerberos RPM itself. It should be possible to assume as a system library for Linux and MacOSX > - Kerberos for Windows: that's not part of the OS -> internalise > (http://web.mit.edu/kerberos/dist/index.html#kfw-3.2) Do we really really need this on Windows? > - LDAP: We already have OpenLDAP-related stuff in configure.in... So > can postgresql-sdbc just use that, or is the existing stuff > "too optional"? I mean it seems to be replacing some Mozilla > parts, not sure we enable it on our builds or if it just a > service to distributions. If cannot just use: > > * MacOS X: is it bundled? Some googling finds LDAP-related commands > in MacOS X 10.4, our baseline. So we are good to > consider it a system lib? > > * GNU/Linux: Debian has stable soname since 2008. Assuming other > distros are similar, is that sufficient to consider it > a system library? So, in LibreOffice, we have two ways of use LDAP: Either we use the ldap functionality from the bundled mozilla, or we use OpenLDAP. > > * Windows: The Microsoft implementation is used, Google tells me it > is in the Windows platform SDK. Our current way to build > libpq does not have an option for enabling LDAP, but > peeking at the official Perl-driven process, it seems > easy enough to hack in: > > ° #define USE_LDAP 1 > > ° link against wldap32.lib Yup, can be done easily. Let me have a try on different options. Cheers Fridrich _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
