Commit c64c99ab authored by Simon McVittie's avatar Simon McVittie

New unresolved point: should we set LD_LIBRARY_PATH?

Reviewed-by: default avatarMathieu Duponchelle <>
Signed-off-by: default avatarSimon McVittie <>
Differential Revision:
parent 1df02729
......@@ -629,6 +629,8 @@ variables, so that they automatically use appropriate directories:
* `XDG_RUNTIME_DIR=/run/user/$uid` (used by `g_get_user_runtime_dir`
and provided automatically by systemd; access is subject to a "whitelist")
**Unresolved:** [](#should-ld_library_path-be-set)
Built-in application bundles should be given the same environment
variables, but with `/usr/Applications` replacing `/Applications`.
......@@ -936,6 +938,21 @@ insufficiently careful? We probably cannot use `+t` permissions (the
because that would prevent one user from deleting a file created by
another user, which is undesired here.
### Should `LD_LIBRARY_PATH` be set?
The Autotools build system (`autoconf`, `automake` and `libtool`) will
automatically configure executables to load libraries built from the same
source tree in their installed locations, using the `DT_RPATH` ELF header,
so it is unnecessary to set `LD_LIBRARY_PATH`.
However, we might wish to set `LD_LIBRARY_PATH=/Applications/${bundle_id}/lib`
(or the obvious `/usr/Applications` equivalent) so that app-bundles built with
a non-Automake build system will "just work".
Similarly, we might wish to set
`GI_TYPELIB_PATH=/Applications/${bundle_id}/lib/girepository-1.0` for
app-bundles that use GObject-Introspection.
## Alternative designs
### Merge static and variable files for store applications
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment