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