Ah, ok. That would seem to be incorrect.
On Wed, Jan 28, 2015 at 12:58 PM, Daniel van Vugt
<daniel.van.v...@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.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
