dlopen cannot load shared library

[Mark Shuttleworth]

On 03/02/17 12:41, Loïc Minier wrote:
> Hi,
>
> On Fri, Feb 3, 2017 at 11:20 AM, Roberto Mier Escandón 
> <roberto.escandon at canonical.com
> <mailto:roberto.escandon at canonical.com>> wrote:
>
>     I'm having a problem with a snap which start certain daemon when
>     installed. This daemon tries to load certain shared library but
>     it's not
>     able to do it even in devmode [1]. However it loads it well in classic
>     mode. The library is in a rw path, provided directly to a dlopen
>     method
>     [1]. Have anybody hit this kind of issue before?
>
>
> In classic mode, you see libraries from your classic Ubuntu system
> including X11; in devmode/confined mode, you only see system libraries
> from the core snap which doesn't contain X11.
>
> I suggest you embed X11 and other libs that your dlopen-ed library
> depends on.

Loic is correct, but let me give a slightly less compressed answer :)

The snap sees a filesystem that is constructed specially for it, out of
a bunch of other filesystems. Just like you can mount a set of disks at
particular paths, for the snap, a set of "disks" are mounted at
particular locations. So what the snap processes "see" as their disk is
specially constructed just for that snap.

In the case of a devmode or strictly confined snap, the root of the
filesystem ("/") is the core snap. That is a tiny heart of Ubuntu (in
future could be Fedora or Debian too) that just has the very core
libraries and binaries. It does not have X11 or any desktop libraries.

So when you switched to devode, your snap processes stop seeing your
"normal hard disk" at / and start seeing the minimal core snap at /.

If you 'ls -l /snap/core/current' on a classic desktop you will see the
filesystem that your snap sees at /. There are no X libraries there :)

That's why you need either:

 * to bundle your X libraries. snapcraft will try to do this for you
automatically. if you are handcrafting your snap then you need to pay
attention to the files in the snap and the loading paths that the linker
uses.

 * to use libraries from another snap which might have shared content
that lots of snaps reuse, in which case if that other snap changes you
might break

Hope that's clearer,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170203/af57ba28/attachment.html>