client funcs in libmircommon

[Daniel van Vugt]

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.
>