Re: LD_LIBRARY_PATH

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: "Andrew W(dot) Nosenko" <awn(at)bcs(dot)zp(dot)ua>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: LD_LIBRARY_PATH
Date: 2000-12-29 12:35:37
Message-ID: Pine.LNX.4.30.0012291319580.822-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Andrew W. Nosenko writes:

> As I understand Mike speak not about files in general but about
> libraries (and possible have in mind executables too). And hardcoded
> patch to libraries is nightmare, IMO.

The deal is this: As a general rule, in any software package that you
build from source via ./configure; make; make install you *must* install
the files at the location that you told configure (with --prefix, etc.).
It may be the case that the particular package doesn't care (e.g., GNU
make doesn't care because it only installs a single executable and some
documentation), but just about any package that installs more than one
file has this requirement. It's not just hardcoded library paths, it's
executables containing paths to data and configuration files, data files
containing paths to library files and other data files, libraries
containing paths to configuration files, etc. So the discussion about
what happens when you move your libraries is essentially pointless.

Certainly, the interface offered by most linkers to control runtime paths
isn't ideal, but it's much better than not having one at all. I'm aware
that there are circumstances where you really don't want to hardcode the
library path. Then you can use 'configure --disable-rpath'.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Dimitris Papadiotis 2000-12-29 12:46:31 ODBC Returns 0 records
Previous Message Gordan Bobic 2000-12-29 12:31:38 Re: MySQL and PostgreSQL speed compare