symlink app lib to common libs
joerg at britannica.bec.de
Thu Apr 28 10:18:11 PDT 2005
On Thu, Apr 28, 2005 at 05:58:46PM +0200, Jonas Sundström wrote:
> They may be ok in a primarily C, CLI-oriented environment,
> but they prevent BeOS GUI apps from being "good citizens".
> (Like the version of Mozilla I'm using.)
That's a design problem of BeOS than. Under Unix, there is no
reason why a shell scripts is inferior to a normal program.
> Sure, argv can be propagated through the wrapper, but a
> shell script can't hold the necessary application metadata
> (supported filetypes, launch flags, etc) by which the system
> "sees" the application (using indexed filesystem attributes),
> and by which the system knows what filetypes the
> application handles, what launch flags are set, etc.
So what? This could be attached the startup script as well.
> And, most importantly, the BeOS C++ API provides a non-argv
> document launch mechanism that can't be passed through
> a wrapper script.
Again, how does this affect UNIX? It's an OS specific calling
mechanism, find an OS specific way to solve it.
> 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).
This is not supposed to help each small program on the system,
but big "packages" like a Tomcat server or a web browser.
More information about the Users