<!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> It seems that, in any non-trivial case, we're going to have to have an application setting up a bunch of environment variables anyway. Whether that be something like LD_LIBRARY_PATH or QML_MODULES_PATH or PYTHON_HOME or anything of the such. Ideally we'd get to the point that all of these libraries would understand the snappy paths and environment variables but I imagine that's quite a ways off. What we gain by making the library directories more flexible is that we can place them in known paths based on the distributor of the libraries, much like we do with applications in snappy. So if you were the python module you could put your libraries in the application package under a "python" directory so that it wouldn't conflict with other build modules that are being used. I think that this direct accountability for who own which file has shown value in the base system, and will also be valuable for build environments. I think what is more interesting is to separate out the environment setup script so that we can perhaps cache the values sometime in the future and replay them. But that is quite simply an optimization we're not at the point of yet. Ted On Mon, 2015-06-15 at 16:43 +0200, Zygmunt Krynicki wrote: <BLOCKQUOTE TYPE=CITE> <PRE> Without mandating shared library layout you will force everyone to use shell scripts to identify this and compensate. I think this is a mistake, all platforms define how shared library lookup works. Unless you expect that all snappy apps will use static linking and go. There is nothing wrong with specifying basic stuff. Thanks ZK On Mon, Jun 15, 2015 at 4:25 PM, Ted Gould <<A HREF="mailto:ted@ubuntu.com">ted@ubuntu.com</A>> wrote: > On Mon, 2015-06-15 at 14:03 +0200, Zygmunt Krynicki wrote: > > As an example, to get lxml (pip installable) working you need to > bundle a few extra libraries that are _not_ handled by anything on the > python side (no tool automates this). I build a smap with plainbox > manually by using rpath to show each of the .so files that python > loads where to load remaining libraries from. It would be very > beneficial if LD_LIBRARY_PATH was defined by snappy launcher so that > rpath is not required. > > > I don't think that the launcher can really set that, as we don't know > exactly what it would be for the particular package. Otherwise we start to > put in magical directory layout things for snaps, which make them harder to > build. > > An idea that has been bouncing around is to provide a global environment > setup script for executing in a snap that perhaps could be used for > something like this. You can imagine for instance that the LD_LIBRARY_PATH > could change depending on architecture for a multi-arch snap. > > Ted > > -- > snappy-devel mailing list > <A HREF="mailto:snappy-devel@lists.ubuntu.com">snappy-devel@lists.ubuntu.com</A> > Modify settings or unsubscribe at: > <A HREF="https://lists.ubuntu.com/mailman/listinfo/snappy-devel">https://lists.ubuntu.com/mailman/listinfo/snappy-devel</A> > </PRE> </BLOCKQUOTE> </BODY> </HTML>