Greg Stark wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>
> > 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.
>
> Why would any pg tools need to be setuid?
I assume he is saying that you would have problems having that set all
the time. You would need to set it only before running pg binaries,
which is a pain.
> > 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.
>
> The normal approach is to use rpath for relocatable installs.
> That's what it's there for.
> Static linking would work too but it's overkill.
The point is that we want someone to be able to do an install, and then
be able to move the pgsql directory. When we use rpath, the installed
binary has a hardcoded path for the libraries.
> But please don't use rpath for installs to standard paths like
> /usr/{local,}/lib. That way lies madness.
We don't. By default it is /usr/local/pgsql/lib, which isn't standard.
I see static linking as perhaps the only clean solution for relocatable
installs that require no user manipulation.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
