problem getting postgres 8.3.1 with xml support to work on Redhat Enterprise Linux 4

"Aswani Kumar" <Aswani.Kumar@idinsight.com> writes:

The Postgres was built using ./configure
XML2_CONFIG=/usr/local/libxml/bin/xml2-config
--prefix=/usr/local/postgresql-8.3.1 --with-libxml. Libxml2-2.6.32 was
built using ./configure --prefix=/usr/local/libxml and is the location
pointed to in the Postgres configure script.

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.

regards, tom lane

Thanks a lot for the help. I changed the /etc/ld.so.conf to include the
libxml2 directories and did /sbin/ldconfig -v . Postgres initdb started
fine after that.

Thanks
Aswin

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, June 27, 2008 4:46 PM
To: Aswani Kumar
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] problem getting postgres 8.3.1 with xml support
to work on Redhat Enterprise Linux 4

"Aswani Kumar" <Aswani.Kumar@idinsight.com> writes:

The Postgres was built using ./configure
XML2_CONFIG=/usr/local/libxml/bin/xml2-config
--prefix=/usr/local/postgresql-8.3.1 --with-libxml. Libxml2-2.6.32

was

built using ./configure --prefix=/usr/local/libxml and is the

location

pointed to in the Postgres configure script.

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.

regards, tom lane

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?
a) by changing /etc/ld.so.conf and making it permanent
b) by running ldconfig to temporary update dynamic loader cache
c) by setting LD_LIBRARY_PATH environment variable to change it for
current session only or even a single program execution

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

On Tue, Jul 01, 2008 at 05:06:54PM +0800, Craig Ringer wrote:

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.

Oh, Linux supprts rpath, it's just that Debian (and some other
distributions IIRC) forbid its use in distributed binaries.

http://people.debian.org/~che/personal/rpath-considered-harmful

The basic problem is that it makes upgrades difficult if not
impossible wihout recompiling everything.

Postgresql has configure options relating to rpath, never used them
though.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/