Re: [Libreoffice] postresql-sdbc bits out of minutes of tech. steering call

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