Re: Postgresql8.4 install breaks Evolution on Ubuntu 9.10 - Mailing list pgsql-general

Magnus Hagander wrote:
> On Sun, Nov 29, 2009 at 16:18, Sachin Srivastava
> <sachin.srivastava@enterprisedb.com> wrote:
>> Libraries the One-Click installer tramples all over include:
>>
>>    libxml2
>>    libssl
>>    libcrypto
>>    libreadline
>>    libtermcap
>>    libuuid
>>
>>
>> Apart from libxml2 (which is now being fixed) all other libraries you
>> mentioned , dint get installed (or copied) to the PGHOME/lib directory if
>> the same name library already present in the system (/lib and /usr/lib).
>
> What happens if they are installed by the packaging system later on?
> Won't that cause a conflict then?

What if the libraries installed by the system package manager have been
built with different options that render them incompatible with the
shipped PostgreSQL binaries? Possibly subtly so, with crashes or data
corruption down the track rather than immediate and obvious failure?

(Arguably the soname should be changed in this case, but in practice the
soname just isn't sufficient for this sort of thing - you need some kind
of "build key" and there's no support in GNU ld and ld.so for such).

I'd say "ffs, just enable rpath" but for the fact that without a wee bit
more work it doesn't handle moving binaries around very well. Mac OS X's
"@executable_path" runtime linker path substitution doesn't seem to have
a standard equivalent on general *nix. Thankfully, GNU ld.so does offer
a similar runtime path substitution - the ${ORIGIN} variable. From the
ld.so manpage:

       $ORIGIN
              ld.so understands the string $ORIGIN (or equivalently
              ${ORIGIN}) in an  rpath  specification  to  mean  the
              directory   containing  the  application  executable.
              Thus, an application located in somedir/app could  be
              compiled with gcc -Wl,-rpath,'$ORIGIN/../lib' so that
              it finds an associated shared library in  somedir/lib
              no  matter  where somedir is located in the directory
              hierarchy.

(There's also some other good stuff under "RPATH TOKEN EXPANSION". If
you haven't read the entirety of the ld.so and ld man pages, you need to
do so *now* if you're packaging apps for binary distribution).

Note that you can build without rpath, or with normal rpaths, and change
them later using the commonly-available chrpath too. For that matter,
you can skip using $ORIGIN and just use a bundled copy of chrpath to set
rpaths on your binaries at install-time.

  http://linux.die.net/man/1/chrpath

So, please, please, PLEASE start using rpath linkage and stop adding
your lib dir to ld.so.conf ! This problem has been around - and solved -
for a very long time, and you'd be much better off using the existing
well-established and robust solutions rather than rolling your own
dangerous workarounds.

--
Craig Ringer