App Bundles

[André Gillibert]

"Brian J. Tarricone" <bjt23 at cornell.edu> wrote:

> LD_LIBRARY_PATH isn't so useful since it rarely contains the entire
> library search path, and is often empty.  On my system, /etc/ld.so.conf
> contains 10 paths in it, and that usually doesn't include the default
> /lib and /usr/lib (at least it need not include those).
> 
I don't see your point. When LD_LIBRARY_PATH is used, /etc/ld.so.conf isn't ignored.
When searching shared libraries, directories are searched in the following order:
1) Directories listed in the DT_RPATH tag contained in the executable file if it exists and DT_RUNPATH doesn't.
2) Directories in the LD_LIBRARY_PATH env var.
3) Directories listed in the ELF DT_RUNPATH tag if it exists.
4) /etc/ld.so.cache which is "compiled" by ldconfig from /etc/ld.so.conf
5) /lib and /usr/lib

Consequently, if an application wants to launch an app bundle and make it use its own shared libraries, it may add this path into the LD_LIBRARY_PATH env var.

Alternatively, the application may simply store a DT_RPATH tag in its executable file, containing the string $ORIGIN/lib (GNU ld feature).

IMO, the later is better as a fork/exec won't bring this dangerous LD_LIBRARY_PATH into child processes.
Just think about an application bundle, bundling its own "standard libraries", such as GLIBC, because it may depend on a specific version or because it's not always installed on all systems (e.g. libXt).
If this application forks/exec another program, the child process will get the bundled libraries rather than the distro libraries, which may cause stability (and security) issues if there are incompatibilities between the bundled library and the distro library.

With DT_RPATH, exec'ed programs won't get these libraries.

Moreover, it makes launching the bundled application easier, since it may be launched from the command line like that.

/path/to/bundle/bin/program

> My use case here is in app with plugins.
For plugins, applications should simply build a path based on their bundle path they get from argv[0] and call dlopen on their own.
IMO, env vars are dangerous for bundled applications, since they're inherited by child processes.
The bundled application may be an application launcher itself!

> If we had XDG_PLUGIN_DIRS, our bundle launcher could dynamically prepend a path
> under our bundle directory to XDG_PLUGIN_DIRS before launching the
> plugin executable.

And how would an application recognize which plugins are compatible with itself in the mess of dirs you would get when chaining bundled applications with fork/exec.

Rule of the thumb:
1) If you want a setting to be inherited by exec'ed processes, use an env var.
2) If you don't want so, use a parameter (argv[0] being one of them).

So, the plugin dir should be pointed by a a parameter.
Since it should be a subdir of the bundled application dir and you've already defined a way to get this dir (argv[0]), the application has everything it needs.

-- 
André Gillibert