Re: Relocatable installs - Mailing list pgsql-hackers

Bruce Momjian wrote:

> Jan Wieck wrote:
>> 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 existence of LD_LIBRARY_PATH 
> 
> Nope.
> 
>> 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.
> 
> OK.
> 
>> 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.
> 
> Static linking of our binaries?  Hmmm.  Makes sense.  We would need a
> special flag for that.  I can add it to the TODO.
> 
> Seems my testing was flawed because I didn't clean out my hard-coded
> directory properly.  I see now:
> 
>     $ bin/initdb
>     bin/initdb: can't load library 'libpq.so.3'
> 
> and I see in my initdb link line:
> 
>     -Wl,-rpath,/usr/local/pgsql/lib

If I remore the whole -rpath thing, and remove the two -L options and 
the -lpq and -lpgport, and add the libpq.a and libpgport.a explicitly to 
the linker call, the psql executable on my Linux box grows from 421761 
to 677682 bytes in size. It is still shared linked against libc, libz, 
libreadline and a bunch of otheres, but all of them are in /lib or 
/usr/lib, so they are standard or system libraries. It does not depend 
on a libpq.so any more, and that is what we want.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #