Re: Re: problem getting postgres 8.3.1 with xml support to work on Redhat Enterprise Linux 4 - Mailing list pgsql-general

From Craig Ringer
Subject Re: Re: problem getting postgres 8.3.1 with xml support to work on Redhat Enterprise Linux 4
Date
Msg-id 4869F3AE.7090402@postnewspapers.com.au
Whole thread Raw
In response to Re: problem getting postgres 8.3.1 with xml support to work on Redhat Enterprise Linux 4  (askel <dummy666@mail.ru>)
Responses Re: Re: problem getting postgres 8.3.1 with xml support to work on Redhat Enterprise Linux 4
List pgsql-general
askel wrote:
> On Jun 27, 5:46 pm, t...@sss.pgh.pa.us (Tom Lane) wrote:
>> Linux isn't real friendly to putting shared libraries outside the
>> standard directories.  If you want to keep libxml2.so in its own directory
>> you'll need to teach the dynamic linker to look there.  See ldconfig.
>
> What could be more friendly than providing few ways to specify where
> to look for shared libraries?

rpath linking, so the executable can have relative (or at least on some
systems absolute) paths to libraries "burned in" at link time. At least
recent-ish versions of the GNU toolchain do support rpath during
linking, and the dynamic linker from glibc can use the rpath information.

The CMake build system supports rpath linking automatically on Linux. I
don't know about libtool or about libtool-free autotools build
environments. The manpage for GNU ld has some information on rpath
linker options.

rpath linking is particularly useful when you want an app to use a
private copy of a library built differently to how the rest of the
system needs that library to be built. You don't  want it to be on the
general library search path, so without rpath you generally land up
having to resort to wrapper scripts.

--
Craig Ringer

pgsql-general by date:

Previous
From: Rafael Martinez
Date:
Subject: Problems with a C function, pg_uname(), and String concatenation.
Next
From: Richard Huxton
Date:
Subject: Re: FTS question