client funcs in libmircommon

[Christopher James Halse Rogers]

Ah, ok. That would seem to be incorrect.

On Wed, Jan 28, 2015 at 12:58 PM, Daniel van Vugt 
<daniel.van.vugt at canonical.com> wrote:
> That's the point. Yes, we do now have a handful of client functions 
> exported from libmircommon directly to (future) clients. So that's 
> why I raised it...
> 
> 
> On 28/01/15 09:55, Christopher James Halse Rogers wrote:
>> On Wed, Jan 28, 2015 at 12:49 PM, Daniel van Vugt
>> <daniel.van.vugt at canonical.com> wrote:
>>> I forgot (and aren't totally sure) about indirect dependencies.
>>> 
>>> Although these client functions are obviously versioned, so even the
>>> indirect dependencies will point to funcname@@MIR_COMMON_3.x which
>>> sounds like it could become a problem for clients/toolkits rather
>>> quickly as we bump the common ABI.
>> 
>> Just to be clear, we're not exporting anything that a client would be
>> expected to directly call from libmircommon, right? The callstack 
>> might
>> go client code→libmirclient→libmircommon, but never client
>> code→libmircommon, right?
>> 
>> In which case the client code never references anything in 
>> libmircommon,
>> it's symbol table contains nothing from libmircommon, and everything 
>> is
>> handled by ld.so when libmirclient is loaded.
>> 
>>> 
>>> 
>>> On 28/01/15 08:57, Christopher James Halse Rogers wrote:
>>>> On Tue, Jan 27, 2015 at 2:50 PM, Daniel van Vugt
>>>> <daniel.van.vugt at canonical.com> wrote:
>>>>> We seem to have some client functions residing in libmircommon 
>>>>> now...
>>>>> 
>>>>> That sounds reasonable at first but doesn't this prevent us from 
>>>>> being
>>>>> able to bump the common ABI without breaking clients?
>>>> 
>>>> No? They'll just link to libmirclient8. The old libmirclient8 will 
>>>> link
>>>> to libmircommon3 and the new libmirclient8 will link to 
>>>> libmircommon4,
>>>> and everything will work as expected.