Thanks Daniel for noticing this. I agree that there may be unforeseen risks even though things seem to work. We should fix this ASAP, preferably with a test case that screams when two versions are loaded simultaneously. Bumping the priority of the bug so it gets proper attention.
-C On Fri, Mar 20, 2015 at 2:40 AM, Daniel van Vugt < daniel.van.v...@canonical.com> wrote: > Maybe as a temporary solution we should have the offending symbols > versioned as "MIR_COMMON_3.1" still from within libmirclient. At least till > the client ABI gets bumped. > > That way existing clients are not forced to load two different versions of > libmircommon simultaneously. > > > > On 20/03/15 15:32, Daniel van Vugt wrote: > >> This is interesting. Since r2408 we do indeed have legacy clients still >> working with newer library builds. So no obvious ABI break. But they >> work because they can load libmircommon.so.3&4 simultaneously. >> >> So everything apparently still works, but I'm a little afraid there >> might be unseen risks with two versions of the same library in one >> process. >> >> [https://bugs.launchpad.net/mir/+bug/1415321/comments/3] >> >> > -- > Mir-devel mailing list > Mir-devel@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/mir-devel > -- Cemil Azizoglu Mir Display Server - Team Lead Canonical USA
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
