After "make install" mir_demo_server cannot find shared object file in /usr/local/lib

The significant step (compared to our usual ways of invoking Mir) appears to be:

    $ make install

What appears to be happening is that /usr/local/lib/ isn't being searched by dlopen() when loading libmir_demo_server_loadable.so. We should probably update the discussion following this install command.

As a workaround it should be possible to:

/1/ run the Mir executable from the build directory. E.g.

    $ sudo bin/mir_demo_server

/2/ Add LD_LIBRARY_PATH=/usr/local/lib/ e.g.

   $ sudo LD_LIBRARY_PATH=/usr/local/lib/ bin/mir_demo_server

Note that option 1 is how we typically run Mir during development, and doesn't need Mir to be installed.

Can we not just make it a static library? Sounds lazy but the existence of libmir_demo_server_loadable.so sounds like a problem in itself. If demo servers require that much shared code to work that they need to use another shared library then it sounds like either that code is destined to move into libmirserver anyway, or it's destined to be discarded. Because in the long run we want to be able to build usable Mir servers using just libmirserver as the common functionality. In my mind, that's a basic requirement -- build an API that is sufficiently simple that all the complex bits you need are already provided in libmirserver. The existence of libmir_demo_server_loadable.so indicates we're not there yet.

Historically, there were problems found downstream with loading plugins based on Mir, so we chose to do the same in the demo server so that we would identify such problems before release.

It seems silly to introduce a separate executable for that scenario just because we've a dlopen problem when using "make install" - there ought to be a better way.

From the POV of a runnable demo it doesn't need to be a library (shared or static) - the code is only needed in mir_demo_server.

I need to create a clean setup and investigate further. dlopen() ought to look in /usr/local/lib as that is specified in /etc/ld.so.conf.d/libc.conf

You might be able to tell ldconfig to cache the new location.

Yep, "sudo ldconfig" refreshes the cache and dlopen() finds libmir_demo_server_loadable.so

The resulting problem is that we end up with two versions of libmirclient.so.9 on the system - and we find the wrong one.

There are a lot of desktop packages dependent on libmirclient9 - so just uninstalling that isn't an option.

Bottom line: Installing mir with "sudo make install" isn't a great idea when mir packages are already on the system.

Oh actually this is similar to issues found in other projects.

All you should need to do is change your target to /usr/lib instead of /usr/local/lib by doing:

$ mkdir build
$ cd build
$ cmake .. -DCMAKE_INSTALL_PREFIX=/usr
$ make
$ make install

On second thoughts, it's a bit weird, and theoretically easy to avoid using dlopen. So this may get fixed.

In the mean time, comment #7 shows how to avoid the problem completely.

I don't think comment #7 avoids the problem.

1. We still end up with two instances of libmirclient.so.9 (as described in comment #6). Vis:

    /usr/lib/libmirclient.so.9
    /usr/lib/x86_64-linux-gnu/libmirclient.so.9

2. ldcache still needs to be refreshed

Things we can do:

i. Don't suggest an (unnecessary) "make install" in the instructions.
ii. Expand the discussion of getting an install working to cover the issues discussed in these comments.

We still need to mention "make install" for non-Debian based distros (which we could support last time desrt checked but that was a while ago and required a little effort). "make install" is potentially the basis for other packaging systems too.

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.19.0

This bug was fixed in the package mir - 0.19.0+16.04.20160128-0ubuntu1

---------------
mir (0.19.0+16.04.20160128-0ubuntu1) xenial; urgency=medium

  [ Brandon Schaefer ]
  * New upstream release 0.19.0
    - API summary:
      . mirclient abi unchanged at 9
      . mirserver abi bumped to 37
      . mircommon abi unchanged at 5
      . mirplatform abi unchanged at 11
      . mirprotobuf abi unchanged at 3
      . mirplatformgraphics abi bumped to 7
      . mirclientplatform abi bumped to 4
      . mirinputplatform abi bumped to 5
      . mircookie abi bumped to 2
    - Bug fix:
      . Mir servers crash on mouse input (LP: #1528438)
      . Pinch to zoom not working reliably (LP: #1531517)
      . Passing DisplayConfiguration scale property from
        nested server to host appears to not work (LP: #1535780)
      . Various TSan reports when running test suite
        on a mir tsan enabled build (LP: #1523647)
      . Buffer leak during repeated mirscreencasts
        causes server to be killed (LP: #1523900)
      . Cursor now displays correctly (LP: #1526779)
      .ProgramOption::parse_file() reports problems to cerr (LP: #1190165)
      . Nested servers can select wrong platform (LP: #1515558)
      . There seems to be missing RTTI information
         when linking with UBSan enabled (LP: #1521930)
      . Mir threadsanitizer build fails with GCC (LP: #1522581)
      . After "make install" mir_demo_server cannot
        find shared object file in /usr/local/lib (LP: #1522836)
      . Fixed a test in TestClientInput (LP: #1523965)
      . Mir servers choose graphics-dummy (or no driver at all)
        over mesa-kms on a desktop (LP: #1528082)
      . Function mir_event_get_close_surface_event is never used (LP: #1447690)
      . mir::input::Surface::consume(MirEvent const& event)
        should not take a reference to an opaque type (LP: #1450797)
      . lintian: E: mir-doc: privacy-breach-logo (LP: #1483471)

  [ CI Train Bot ]
  * No-change rebuild.

 -- Brandon Schaefer <email address hidden> Thu, 28 Jan 2016 12:19:47 +0000