The wrong libmirplatformgraphics.so is loaded in CI (which causes bugs and crashes during CI)

[Alan Griffiths]

I'm basing this on circumstantial evidence originating from the investigation of lp:1358698.

In two places: DefaultConfiguration::add_platform_options() and SharedLibrary.load_valid_library_works we load a library with the name "libmirplatformgraphics.so".

If things are happening correctly this loads the version built as part of the current build. But if this is forced to fail then the version loaded is that installed elsewhere on the system.

That is clearly not appropriate when running the tests (but not noticed as most tests stub out this functionality).

The problem seen in lp:1358698 followed from this when the installed libmirplatformgraphics.so introduces a different version of libmircommon to that belonging to the build under test.

However, it is wrong to be loading the installed libmirplatformgraphics.so at all - and that is the problem this bug report is about.

[Chris Halse Rogers (raof)]

This turns out to be a CI setup issue, which should be fixed in http://bazaar.launchpad.net/~mir-team/+junk/mir-medium-test-runner-for-jenkins/revision/30

Specifically - since our stacks aren't (yet) parallel installable, the CI setup needed to keep both libmirserver24 and libmirserver25 around. The only way to do that is to have both libmirplatformgraphics-android and libmirplatformgraphics-mesa installed, but different versions of each, one for libmirserver24 and one for libmirserver25.

Due to the order we specify the dependencies - and the fact that only libmirplatform-graphics-android is installed on the device pre-CI - the solution apt chose is to leave the old libmirplatformgraphics-android installed and install the new libmirplatform-graphics-mesa.

With hilarious consequences!

[Daniel van Vugt (vanvugt)]

Wait a minute... Fix released where?