Magnus Hagander wrote:
> On Sun, Nov 29, 2009 at 16:18, Sachin Srivastava
> <sachin.srivastava@xxxxxxxxxxxxxxxx> 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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
