Subject: Multiple personalities

From: Daniel van Vugt <[email-masked]>
Date: Fri, 20 Mar 2015 15:32:39 +0800

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]

---

From: Daniel van Vugt <[email-masked]>
Date: Fri, 20 Mar 2015 15:40:06 +0800

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.

---

From: Cemil Azizoglu <[email-masked]>
Date: Sun, 22 Mar 2015 11:33:43 -0500

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 <
[email-masked]> wrote:

> 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.
>
>
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
>

-- 
Cemil Azizoglu
Mir Display Server - Team Lead
Canonical USA

---

From: Alan Griffiths <[email-masked]>
Date: Mon, 23 Mar 2015 11:54:37 +0000

> till the client ABI gets bumped.

I don't think that would work - as (using your example)
mir_demo_client_fingerpaint has direct dependencies on
libmircommon.so.3  (MIR_COMMON_3.1) and libmircommon.so.3 (MIR_COMMON_3).

---

From: Alan Griffiths <[email-masked]>
Date: Mon, 23 Mar 2015 11:59:22 +0000

It isn't elegant to load two versions of a library but I don't think it
matters at present which version of the mir_*event_get* functions is
resolved - they simply moved (and don't depend on static data). The
alternative is to bump the client ABI (as was initially proposed in
https://code.launchpad.net/~alan-griffiths/mir/fix-1415321/+merge/253077).

FWIW We've had other silent ABI infelicities thanks to the the wildcards
in MIR_CLIENT_8 accidentally publishing symbols in the wrong stanza.

On 22/03/15 16:33, Cemil Azizoglu wrote:
> 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
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     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.
>
>
>
>     [email-masked] <mailto:[email-masked]>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>
>
>
> -- 
> Cemil Azizoglu

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 24 Mar 2015 10:03:57 +0800

Yeah I'm glad we're now rid of the broad wildcarding mistake in 
symbols.map. But that was less of an issue. Functions were pulled from 
the right library, just with incorrect symbol versions.

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Thu, 26 Mar 2015 18:19:00 +1100

> simultaneously. Bumping the priority of the bug so it gets proper 

This is guaranteed¹ to work, thanks to our symbol versioning. 
Everything is going to resolve the symbol it expects, and - as long as 
we're not mixing different versions - anything passed between DSOs will 
agree on the symbol.

¹: Modulo stupid non-idempotent globals, like protobuf

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 26 Mar 2015 15:34:57 +0800

Guaranteed to work... unless we change a structure definition and it 
gets say created by libmircommon.so.4 and then used by a function in 
libmircommon.so.3.

But that hasn't happened yet, and probably won't.

On 26/03/15 15:19, Christopher James Halse Rogers wrote:
> This is guaranteed¹ to work, thanks to our symbol versioning. Everything
> is going to resolve the symbol it expects, and - as long as we're not
> mixing different versions - anything passed between DSOs will agree on
> the symbol.
>