Thread: LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP

LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP

From
Lionel Elie Mamane
Date:
Hi,

I've revived the old moribund / bitrotten OpenOffice driver for
PostgreSQL (originally at
http://dba.openoffice.org/drivers/postgresql/index.html). As you may
already know, OpenOffice was forked into LibreOffice. Barring any
unforeseen disaster, LibreOffice 3.5 (to be released in early February
2011) will bundle that driver.

As part of this integration, I have a few questions / remarks.

LibreOffice can be configured at build-time to use Mozilla LDAP or
OpenLDAP. We patched postgresql's configure.in to build libpq with
Mozilla LDAP when requested to do so.

I wanted to check that this is not by any chance known to produce a
more-or-less subtly broken libpq.

I'd also be happy to extract from our patch the parts that are
relevant for integration in postgresql proper, and massage them into
the right modularity / form. Are you interested?

-- 
Lionel


Lionel Elie Mamane <lionel@mamane.lu> writes:
> I've revived the old moribund / bitrotten OpenOffice driver for
> PostgreSQL (originally at
> http://dba.openoffice.org/drivers/postgresql/index.html). As you may
> already know, OpenOffice was forked into LibreOffice. Barring any
> unforeseen disaster, LibreOffice 3.5 (to be released in early February
> 2011) will bundle that driver.

Cool ...

> As part of this integration, I have a few questions / remarks.

> LibreOffice can be configured at build-time to use Mozilla LDAP or
> OpenLDAP. We patched postgresql's configure.in to build libpq with
> Mozilla LDAP when requested to do so.

Um, if I interpret this correctly, you're intending to make OpenOffice
include a bundled copy of libpq.so.  With my other hat on (the red
fedora) that sounds like a truly awful idea.  Distros do not like
packages that include bundled copies of other packages' libraries,
because they're a nightmare for updates (cf recent discussions about
static libraries, which are the same thing).  I strongly suggest you
find a way to not need to do this.

> I wanted to check that this is not by any chance known to produce a
> more-or-less subtly broken libpq.

No, we are not going to make any promises about that.
        regards, tom lane


Re: LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP

From
Lionel Elie Mamane
Date:
On Tue, Dec 13, 2011 at 10:43:26AM -0500, Tom Lane wrote:
> Lionel Elie Mamane <lionel@mamane.lu> writes:

>> LibreOffice can be configured at build-time to use Mozilla LDAP or
>> OpenLDAP. We patched postgresql's configure.in to build libpq with
>> Mozilla LDAP when requested to do so.

> Um, if I interpret this correctly, you're intending to make
> OpenOffice include a bundled copy of libpq.so. With my other hat on
> (the red fedora) that sounds like a truly awful idea.

In the "traditional Unix" world (GNU/Linux, Free/Net/Open/MirBSD,
...), libpq.so.5 is in the dynamic linker's default search path, so we
can conceivably link against it and tell ours users "install package
libpq5 / postgresql-client-lib / ... if you want PostgreSQL support".

On MacOS X and Microsoft Windows, the world is far more messy. There
are several ways to install libpq (one-click installer, fink,
MacPorts, ...), and each of these ways allows the user to select an
install location (or a prefix thereof) freely. How we are supposed to
instruct the dynamic linker to find libpq on the user's system, you
tell me, I have no better idea than bundling it (or linking
statically); runningfind / -name libpq.5.dylib
(or libpq.dll on Windows) and then dynamically running otool (the
MacOS X equivalent of chrpath/patchelf/...) on ourselves is *not*
practical, to say the least...

> Distros do not like packages that include bundled copies of other
> packages' libraries,

"Traditional Unix" distros are free to (and I expect typically will)
configure LibreOffice with --with-system-libs or
--with-system-postgresql (which will use pg_config in the PATH) or
--with-libpq-path=/foo/bar, all of which will just link against libpq
and not bundle it, and expect to find it at runtime at the same
location than at compile-time or in the dynamic linker's default
search path. Their RPM/DEB/... will declare a dependency on the
RPM/DEB/... that ships an ABI-compatible libpq.so.5, so it will be
there and all will be well.

With my Debian GNU/{Linux,kFreeBSD,Hurd,...} hat on, obviously I would
not have it any other way. With my LibreOffice hat on, I have to take
care of other platforms' needs, too.

> because they're a nightmare for updates (cf recent discussions about
> static libraries, which are the same thing).  I strongly suggest you
> find a way to not need to do this.

Personally, I don't have a beginning of a clue of a "way to not need
to do this" for MacOS X and Microsoft Windows. The MacOS X & Windows
guys within LibreOffice tell me bundling the lib (or linking
statically) is the least insane thing to do on these
platforms. <shrug>

-- 
Lionel


Re: LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP

From
Greg Smith
Date:
On 12/13/2011 11:07 AM, Lionel Elie Mamane wrote:
> On MacOS X and Microsoft Windows, the world is far more messy. There
> are several ways to install libpq (one-click installer, fink,
> MacPorts, ...), and each of these ways allows the user to select an
> install location (or a prefix thereof) freely.

This is less controversial.  If you yell at Tom about something messy 
that must be done only to support Windows and Mac OS X, he does 
something completely different with his RedHat Fedora.  It's kind of 
like http://www.youtube.com/watch?v=kLbOMb7F40k , only more red.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us



Greg Smith <greg@2ndQuadrant.com> writes:
> On 12/13/2011 11:07 AM, Lionel Elie Mamane wrote:
>> On MacOS X and Microsoft Windows, the world is far more messy. There
>> are several ways to install libpq (one-click installer, fink,
>> MacPorts, ...), and each of these ways allows the user to select an
>> install location (or a prefix thereof) freely.

> This is less controversial.

Yeah, I'm aware that sane handling of library dependencies is
practically impossible under Windows, but I didn't see how that would
result in wanting to change the configure script.  I wasn't thinking
about OSX though.  (You're aware that Apple ships a perfectly fine
libpq.so in Lion, no?)
        regards, tom lane


Re: LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP

From
Lionel Elie Mamane
Date:
On Tue, Dec 13, 2011 at 12:48:01PM -0500, Tom Lane wrote:
> Greg Smith <greg@2ndQuadrant.com> writes:
>> On 12/13/2011 11:07 AM, Lionel Elie Mamane wrote:

>>> On MacOS X and Microsoft Windows, the world is far more messy. There
>>> are several ways to install libpq (one-click installer, fink,
>>> MacPorts, ...), and each of these ways allows the user to select an
>>> install location (or a prefix thereof) freely.

>> This is less controversial.

> Yeah, I'm aware that sane handling of library dependencies is
> practically impossible under Windows, (...).  I wasn't thinking
> about OSX though.  (You're aware that Apple ships a perfectly fine
> libpq.so in Lion, no?)

No, I was not aware of that. Thank you for that information. Is it
installed by default?

Anyway, LibreOffice wishes to be compatible back to MacOS X 10.4
(probably to have some sort of MacOSX/PowerPC support), so that's not
yet useful to us, but it is good news! As I use PQconnectdbParams, I
also need version 9.0 or later (but I'd be willing to work around that
if it were useful).

-- 
Lionel


Re: LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP

From
Pavel Golub
Date:
Hello, Tom.

You wrote:

TL> Greg Smith <greg@2ndQuadrant.com> writes:
>> On 12/13/2011 11:07 AM, Lionel Elie Mamane wrote:
>>> On MacOS X and Microsoft Windows, the world is far more messy. There
>>> are several ways to install libpq (one-click installer, fink,
>>> MacPorts, ...), and each of these ways allows the user to select an
>>> install location (or a prefix thereof) freely.

>> This is less controversial.

TL> Yeah, I'm aware that sane handling of library dependencies is
TL> practically impossible under Windows, but I didn't see how that would
TL> result in wanting to change the configure script.  I wasn't thinking
TL> about OSX though.  (You're aware that Apple ships a perfectly fine
TL> libpq.so in Lion, no?)

Is it true? Really? Where can we read about it?

TL>                         regards, tom lane




-- 
With best wishes,Pavel                          mailto:pavel@gf.microolap.com



Pavel Golub <pavel@microolap.com> writes:
> You wrote:
> TL> about OSX though.  (You're aware that Apple ships a perfectly fine
> TL> libpq.so in Lion, no?)

> Is it true? Really? Where can we read about it?

/Library/WebServer/Documents/postgresql/html ...

I don't know where else Apple documents this, but there's a
complete-looking set of client-side libraries and command line tools
from Postgres 9.0.4 in base Lion.  I understand that if you buy Lion
Server you get the postmaster too, but I haven't done that so I can't
verify it from personal experience.  libpq.dylib is definitely right
there in /usr/lib though, and it apparently is well-configured, because
/usr/bin/pg_config says

CONFIGURE = '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-dependency-tracking' '--prefix=/usr'
'--sbindir=/usr/libexec''--sysconfdir=/private/etc' '--localstatedir=/var/pgsql'
'--htmldir=/Library/WebServer/Documents/postgresql''--enable-thread-safety' '--enable-dtrace' '--with-tcl'
'--with-perl''--with-python' '--with-gssapi' '--with-krb5' '--with-pam' '--with-ldap' '--with-bonjour' '--with-openssl'
'--with-libxml''--with-libxslt' '--with-system-tzdata=/usr/share/zoneinfo' 'CFLAGS=-arch x86_64 -arch i386 -pipe -Os -g
-Wall-Wno-deprecated-declarations' 'LDFLAGS=-arch x86_64 -arch i386 -pipe -Os -g -Wall -Wno-deprecated-declarations'
'LDFLAGS_EX=-mdynamic-no-pic'

I've not made an attempt to use it directly myself, but it sure looks
like it should do what the OP wants.
        regards, tom lane


Re: LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP

From
Lionel Elie Mamane
Date:
On Tue, Dec 13, 2011 at 11:45:28AM +0100, Magnus Hagander wrote:
> On Tue, Dec 13, 2011 at 11:15, Lionel Elie Mamane <lionel@mamane.lu> wrote:

>> LibreOffice can be configured at build-time to use Mozilla LDAP or
>> OpenLDAP. We patched postgresql's configure.in to build libpq with
>> Mozilla LDAP when requested to do so.

>> I'd also be happy to extract from our patch the parts that are
>> relevant for integration in postgresql proper, and massage them into
>> the right modularity / form. Are you interested?

> Please do.

The patch is attached. I got everybody that touched the patch in the
LibreOffice git repo to agree to the PostgreSQL license for the patch.

The changes to tools/msvc are untested since I don't personally have a
Microsoft Windows build environment and LibreOffice uses
src/interfaces/lipq/win32.mak to build libpq.

The patch introduces a preprocessor macro USE_MICROSOFT_LDAP to enable
the Microsoft LDAP part to replace the previously used "#ifdef WIN32",
since one can also use Mozilla LDAP on MS Windows. I found that
cleaner than putting everywhere "#if defined(WIN32) && ! defined(USE_MOZLDAP)".

Except for that, the only change is to the config/build system proper,
to recognise and use the Mozilla LDAP library.

--
Lionel

Attachment

Re: LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP

From
Lionel Elie Mamane
Date:
On Wed, Dec 14, 2011 at 10:05:26AM -0500, Tom Lane wrote:
> Pavel Golub <pavel@microolap.com> writes:
>> You wrote:

>> TL> about OSX though.  (You're aware that Apple ships a perfectly fine
>> TL> libpq.so in Lion, no?)

> I've not made an attempt to use it directly myself, but it sure looks
> like it should do what the OP wants.

Yes, it looks like that, except for being available on older MacOS X;
LibreOffice wished to stay compatible with 10.4.

-- 
Lionel