Skip site navigation (1) Skip section navigation (2)

Re: Postgresql8.4 install breaks Evolution on Ubuntu 9.10

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: pgsql-general(at)postgresql(dot)org, sachin(dot)srivastava(at)enterprisedb(dot)com
Subject: Re: Postgresql8.4 install breaks Evolution on Ubuntu 9.10
Date: 2009-11-29 13:40:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
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/ 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/ or 
modifying the global LD_LIBRARY_PATH.


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:

   "${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 . 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

In response to


pgsql-general by date

Next:From: Martin GaintyDate: 2009-11-29 13:47:19
Subject: Re: Time zone 'GMT+8'
Previous:From: Ivan Sergio BorgonovoDate: 2009-11-29 12:21:45
Subject: duplicating a schema

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group