This bug is recording an idea that came up during the Snapcraft Summit but we didn't have time to implement. At the moment, Snapcraft runs patchelf on every ELF file in classic snaps in order to alter DT_RPATH. It would be nice to patch fewer files because it can inflate the size of the executables, and takes time to perform. According to this article: http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/ ... the search order for loading libraries is: Unless loading object has RUNPATH: RPATH of the loading object, then the RPATH of its loader (unless it has a RUNPATH), ..., until the end of the chain, which is either the executable or an object loaded by dlopen Unless executable has RUNPATH: RPATH of the executable LD_LIBRARY_PATH RUNPATH of the loading object ld.so.cache default dirs So we only need to make sure executables and objects opened with dlopen have DT_RPATH set: any libraries loaded by those executables will inherit their RPATH(s). That begs the question of how to identify these files. The following algorithm should be a good approximation of this: 1. identify the set of all ELF files in the snap. 2. for each ELF file in the set, extract DT_SONAME and all libs listed in DT_NEEDED 3. create a set of all libraries included in some ELF file's DT_NEEDED 4. remove any ELF file from the first set whose DT_SONAME appears in the DT_NEEDED set 5. the remaining ELF files need patching It isn't particularly bad if this algorithm identifies false positives: it would just result in more patching. A false negative would be a library that is loaded by the dynamic linker normally in one place, and via dlopen elsewhere. And that is only a problem if the dlopen() occurs in an executable that hasn't already loaded the library.