symlink app lib to common libs

[Walter]

Jonas Sundström wrote:
Joerg Sonnenberger <joerg at xxxxxxxxxxxxxxxxx> wrote:
 ...
About including the libs. If app/lib was supported, how is it
any harder to replace an old or insecure "libfoo" in all your
app/lib folders than it is to replace it in one shared lib folder?
THAT'S NOT THE PROBLEM. The problem is storing a _relative_ rpath
in the executable, which can create a lot of *very* nasty problems.
Google a bit, e.g. for the -L handling of SunOS and AIX (IIRC).


Acknowledged.

This looks relevant:
http://www.visi.com/~barr/ldpath.html
I found the last paragraph interesting:
"
Solaris 7 has a neat idea. There you can can specify a run time path 
which is also evaluated at run time. You link with an rpath of $ORIGIN/
../lib. Here, $ORIGIN evaluates at run time to be the installation path 
of the binary. Now you can move the installation tree to another 
location entirely and everything will still work. We need this in other 
OS's! Unfortunately, at least in Solaris 7, $ORIGIN is considered a 
"relative" path (you can subvert it if you have a writable directory on 
the same filesystem because UNIX lets you hard link even a setuid 
executable) so it is ignored on setuid/setgid binaries. Sun has fixed 
this in Solaris 8. You can specify with crle(1) paths that are 
"trustworthy". 
"

/Jonas Sundström.                www.kirilla.com

Let me throw this out, fwiw:
I've pondered this before and thought that a "!" (exclamation
mark) could be used to signify the app dir.
"!/lib/" would be the app's lib directory and nowhere else
"!/apache.ini" would be an init file in the app dir (only)
"!/users/config.ini" - another app specific sub-dir/file
".." would never be allowed
"!" would not be allowed to be other than the first char in a file spec
But programs could effectively do this with the proper calls
to find what directory they sit in, no?  So maybe the issue
is with the programmer rather than the OS or app.