On Mon, Aug 9, 2010 at 3:55 PM, Patrick Ohly <[email protected]> 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 _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
