symlink app lib to common libs

[Joerg Sonnenberger]

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.

Joerg