why does find_my_exec resolve symlinks?
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@sss.pgh.pa.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?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
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.
If it were all that common, we'd have heard people complaining before.
The reason for this behavior is
commit 336969e490d71c316a42fabeccda87f798e562dd
Author: Tom Lane <tgl@sss.pgh.pa.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.
IIRC, the idea was that /usr/bin/postgres might be a symlink to
/usr/local/pgsql/9.4.1/bin/postgres. If we stop resolving symlinks,
that type of arrangement will break :-(. Given that it's been like
this for ten years without previous complaints, I'm disinclined to
mess with it ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers