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
|
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: