Re: LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP - Mailing list pgsql-hackers

From Lionel Elie Mamane
Subject Re: LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP
Date
Msg-id 20111213160739.GB5178@capsaicin.mamane.lu
Whole thread Raw
In response to Re: LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Command Triggers
Next
From: Alvaro Herrera
Date:
Subject: Re: foreign key locks, 2nd attempt