From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | why does find_my_exec resolve symlinks? |
Date: | 2015-02-13 18:42:07 |
Message-ID: | 54DE457F.2090206@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Here is a scenario:
./configure --prefix=/usr/local/pgsql/9.4.1
make
make install
ln -s 9.4.1 /usr/local/pgsql/9.4
PATH=/usr/local/pgsql/9.4/bin:$PATH
And then when 9.4.2 comes out, the symlink is updated.
I think this sort of setup in variations is not uncommon.
When building other software against that installation, it would use
pg_config --includedir, pg_config --libdir, etc., but that points to
/usr/local/pgsql/9.4.1/lib instead of /usr/local/pgsql/9.4/lib, because
find_my_exec() goes out of its way to resolve symlinks in the returned
path. If the other software saves an rpath or the bindir or something
during the build, then if I later clear out the old 9.4.1 installation,
the other software will break.
The reason for this behavior is
commit 336969e490d71c316a42fabeccda87f798e562dd
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Sat Nov 6 23:06:29 2004 +0000
Add code to find_my_exec() to resolve a symbolic link down to the
actual executable location. This allows people to continue to use
setups where, eg, postmaster is symlinked from a convenient place.
Per gripe from Josh Berkus.
I don't quite understand what setup Josh was using there.
Is there a way we can consolidate these situations?
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-02-13 20:36:17 | Re: Refactoring GUC unit conversions |
Previous Message | Fujii Masao | 2015-02-13 18:01:22 | Re: pg_basebackup may fail to send feedbacks. |