On Mon, Aug 9, 2010 at 3:55 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mon, 2010-08-09 at 12:02 +0100, Patrick Ohly wrote:
> The glib vs Bluez gdbus conflict strikes again. This time it is not just
> a runtime symbol. It seems that some glib header pulls in the glib gdbus
> definitions, which happens to conflict with the Bluez ones.
>
> Possible solutions:
> 1. search/replace s/gdbus/gdbus2/ in the Bluez source code as
> bundled with SyncEvolution
> 2. compile it as C++ inside a namespace
> 3. replace it with the new glib and compile the relevant files with
> SyncEvolution for distros with older glib
>
> 3. is the right solution long-term. Patches welcome :-/
>
> 1. is fairly intrusive and prevents exchanging patches with Bluez. 2.
> might be doable without too much work, so I'll look into that.
It turned out that option 1 is easier than 2. Part of the problem was
that C code does not necessarily compile as C++ (implicit cast from void
*; bit operations on enums result in int, which cannot be assigned to
enum).
Attached are patches for SyncEvolution 1.0.1. They are also in the
"dbus-name-conflict" branch in git. With "g_dbus" renamed to
"b_dbus",
linking libgdbus.a statically should no longer be necessary to avoid the
crashes that we saw before, so I also reverted that.
Peter, would you mind trying them out on Fedora? I gave them some light
testing, but not on a system which actually has a conflicting glib.
Thanks, BTW, for bringing up these issues.
I can but one query. You mention in 1 " in the Bluez source code as
bundled with SyncEvolution" but you mention elsewhere on the thread
that it would only use the bundled libraries if the system libraries
weren't present. So surely this should be using the system bluez
rather than the local bluez.
Peter