Bruce Momjian wrote:
> Jan Wieck wrote:
>> > I think if we go for the plan outlined, we will not need a special
>> > configure flag. (People might decide to move the install dir long after
>> > they install it.) By default, everything sits under pgsql as pgsql/bin,
>> > pgsql/lib, etc. I can't see how making it relative is going to bite us
>> > unless folks move the binaries out of pgsql/bin. Is that common for
>> > installs that don't specify a special bindir?
>> >
>>
>> Does that include a mechanism for -rpath?
>>
>> Currently, if you have multiple installations of PostgreSQL on a server
>> and call ones psql or whatever explicitly, it is not loading another
>> ones libpq, but for sure the one belonging to its version. How does the
>> plan you're talking about cover this?
>
> Someone asked about rpath, and I didn't deal with it. How many
> platforms use rpath? I am not sure.
>
> I assume folks are going to have to modify their ld.so.conf to point to
> the proper library, or for non-root, set an environment variable like
> LD_LIBRARY_PATH.
You know how much trouble that causes? The existance of LD_LIBRARY_PATH
in your environment disables setuid() for security reasons on some
platforms. So one would have to wrap every PG related program into
equally named shell scripts or aliases to just set it for the program
call alone.
Relocatable installation means static linking of our tools against our
own libs. This does not mean static linking entirely, but at least
static linking against libpq.a.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #