Re: Postgresql8.4 install breaks Evolution on Ubuntu 9.10

On 28/11/2009 7:10 PM, Magnus Hagander wrote:
> On Sat, Nov 28, 2009 at 11:53, Leonardo Camargo
> <camargoleonardo(at)gmail(dot)com> wrote:
>> Hi all,
>> I'm wondering if someone here know how to go about fixing this problem that
>> apparently affects everyone who manually install Postgresql8.4 on Ubuntu
>> Karmic(9.10).
>>
>> Postgres installation seems to mess with something that renders other
>> applications unable to function. For instance my problem is with Evolution
>> Mail. This is the output I started getting after installing postgres:
>>
>> evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
>> available (required by evolution)

> This looks like an install from the 1-clicks, right? It looks to me
> that it's not karmic-compatible - try installing the debian packages
> instead (should be a simple apt-get install postgresql-8.4 - it's
> included by default in Karmic IIRC). I've done that many times without
> any issues like this.

It's not just incompatible - it's a very poorly behaved installer. It's
apparently adding /opt/PostgreSQL/8.4/lib/ to /etc/ld.so.conf or
modifying the global LD_LIBRARY_PATH.

*BAD IDEA*

If you install any libraries not private to the application *and* very
carefully versioned by soname, you shouldn't be making them visible to
the system linker. If you do, things like this happen. This is a
particularly apalling mistake with such common libraries as libxml2,
which are typically not only used by other apps, but provided as part of
the core packages in the system.

If you need to provide your own versions of such libraries, keep them in
a private directory that's never added to the system linker path.
Executables that need access to them should use rpath linking to access
them if at all possible.

If for some reason you won't or can't use rpath linking, which was
designed to solve this problem, you should use wrapper scripts instead.
Eg, if "psql" required access to libxml2, it could be wrapped as:

#!/bin/sh
PGDIR=/opt/PostgreSQL/8.4/
LD_LIBRARY_PATH="${PGDIR}/lib:${LD_LIBRARY_PATH}"\
"${PGDIR}/bin.real/psql" "#@"

where "bin.real/psql" is the real psql binary, which does not appear on
the PATH. Note that the above exactly preserves all command line args,
and will handle spaces in paths etc without issues.

Another alternative if rpath linking is for some reason rejected and
wrapper scripts are considered (understandably) too ugly is to build
your own versions of the libraries you need with different names that'll
be completely unique, eg pg841libxml2.so . You'll run into some *ugly*
global static data issues this way, though, if other code (possibly user
or plugin code) loads a system version of the same library and it has
any global statics.

So - just use rpath linkage for your added libraries, storing them in a
private directory. Please.

(IMO this is about the only area Windows has a significant advantage in
linking by the way - it loads shared libraries from the directory in
which a binary resides preferentially to all others. There'd be security
issues doing so on *nix, but I'm pretty sure they could be worked around
with appropriate ownership and permissions checks).

--
Craig Ringer