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. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
