<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/4.8.5"> </HEAD> <BODY> On Thu, 2015-08-20 at 11:24 +0200, Michael Zanetti wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On 19.08.2015 17:23, Loïc Minier wrote: > On Tue, Aug 18, 2015 at 10:37 PM, Seth Arnold <<A HREF="mailto:seth.arnold@canonical.com">seth.arnold@canonical.com</A> > <<A HREF="mailto:seth.arnold@canonical.com">mailto:seth.arnold@canonical.com</A>>> wrote: > > ld-linux.so.2 will use directories in DT_RUNPATH dynamic section > attribute, which support several variables, $ORIGIN and $PLATFORM look > most useful. See ld.so(8) for details. This might avoid the need for > wrappers entirely. > > > Good points; I had proposed using chrpath in a previous discussion, but > had totally forgotten about $ORIGIN. > > We probably still need the wrappers to find the right binary for this or > that architecture though. Again, with click there's no need for those at all any more. It sets up the environment in a way that it picks the right lib/<arch-triplet>/bin/ folder. Unless there's some other problem with this that I'm not aware of, I think (from an app dev POV) this has been an elegant solution. </PRE> </BLOCKQUOTE> That's not really a click thing as much as UAL sets up the environment for the application. The core launcher can do that as well, and probably should. I don't think that long term it makes as much sense to write actual wrappers to /apps/bin as much as make the core launcher smarter. And once we start doing higher level apps we'll have the core-launcher and UAL work together, so for apps it'll be mostly transparent. I think we need to figure out the default environment discussion (on snappy list) before we can quite see how binaries (if we have a custom shell I think they should be renamed to commands) will work. Ted </BODY> </HTML>