<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 24, 2015 at 5:57 PM, Jamie Strandboge <span dir="ltr"><<a href="mailto:jamie@canonical.com" target="_blank">jamie@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Actually, I have a question:<br>
<br>
Currently the thinking is that an app may declare its dependency on 0 or more<br>
frameworks and may also itself declare its own overlay, with the overlayfs idea,<br>
the launcher will mount the frameworks in order on top of each other, with the<br>
app overlay on top of that, then exec the program.<br>
<br>
It seems like we could achieve this with the LD_PRELOAD idea by requiring the<br>
frameworks to each ship a preloadable library, then the launcher builds up the<br>
LD_PRELOAD list appropriately before launching the app. This could be made to<br>
work, but I wonder if we think hard about multiple frameworks and an app overlay<br>
with LD_PRELOAD in mind, if there is a simpler way.<br>
<br>
Michael, had you considered the above use case when investigating your idea?</blockquote><div><br></div><div>I hadn't considered that case, no.  Currently, my preload library works by looking at an environment variable for its new overlay root.  But I imagine that instead of loading multiple libraries, we could instead make that variable a list of directories.  And whatever code sets that environment variable could determine the list of overlay directories from the set of frameworks the app needs.</div></div><div><br></div><div>And that's simpler than a chain of preloaded libraries too.</div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-mt</div></div>
</div></div>