3:22 p.m.
Hi Patrick,
I'm not quite sure what's changed recently but I suspect its one of
the newer versions of something in Fedora 14 but the syncevolution
build is broken again. Full log can be found here
http://koji.fedoraproject.org/koji/getfile?taskID=2387693&name=build.log
Peter
11:02 a.m.
On Sun, 2010-08-08 at 16:22 +0100, pbrobinson(a)gmail.com wrote:
Hi Patrick,
I'm not quite sure what's changed recently but I suspect its one of
the newer versions of something in Fedora 14 but the syncevolution
build is broken again.
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.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
12:22 p.m.
On Mon, Aug 9, 2010 at 12:02 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Sun, 2010-08-08 at 16:22 +0100, pbrobinson(a)gmail.com wrote:
> Hi Patrick,
>
> I'm not quite sure what's changed recently but I suspect its one of
> the newer versions of something in Fedora 14 but the syncevolution
> build is broken again.
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.
I wonder what other project do? I'm fairly certain that they don't
bundle stuff. Come to think of it the breakage came when I installed
the bluez-devel libraries to enable blue tooth support. So I think
there shouldn't be copies of any local libraries and then if its
required to support various different versions look at what others do.
At a guess autoconf stuff with various ifdef foo or explicitly
requiring a particular version of a libary.
Peter
12:49 p.m.
On Mon, 2010-08-09 at 13:22 +0100, pbrobinson(a)gmail.com wrote:
I wonder what other project do? I'm fairly certain that they
don't
bundle stuff.
For Bluez gdbus: it is always bundled with the apps using it. It is
somewhere between "too small" to release separately and "large
enough"
to be worthwhile sharing.
Regarding bundling libraries in general: it isn't necessary for distros,
but for users who need to build from source on older distros it can be
useful.
I try to keep SyncEvolution fully usable on Ubuntu 8.04 LTS and later
distros when compiling from source, without having to compile anything
besides SyncEvolution.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
1:40 p.m.
On Mon, Aug 9, 2010 at 1:49 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mon, 2010-08-09 at 13:22 +0100, pbrobinson(a)gmail.com wrote:
> I wonder what other project do? I'm fairly certain that they don't
> bundle stuff.
For Bluez gdbus: it is always bundled with the apps using it. It is
somewhere between "too small" to release separately and "large
enough"
to be worthwhile sharing.
Regarding bundling libraries in general: it isn't necessary for distros,
but for users who need to build from source on older distros it can be
useful.
I try to keep SyncEvolution fully usable on Ubuntu 8.04 LTS and later
distros when compiling from source, without having to compile anything
besides SyncEvolution.
In that case it should check for system libraries first and use them
when available an only fall back as necessary. The problem with budled
libraries is security issues. If there's a security issue that the
local distro fixes it should use the local version of the library to
ensure sync evo isn't affected.
Peter
2:08 p.m.
On Mon, 2010-08-09 at 14:40 +0100, pbrobinson(a)gmail.com wrote:
On Mon, Aug 9, 2010 at 1:49 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> I try to keep SyncEvolution fully usable on Ubuntu 8.04 LTS and later
> distros when compiling from source, without having to compile anything
> besides SyncEvolution.
In that case it should check for system libraries first and use them
when available an only fall back as necessary.
Agreed, and SyncEvolution does. Did you have the impression that it
doesn't?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
2:55 p.m.
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.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
3:23 p.m.
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
3:31 p.m.
On Mon, 2010-08-09 at 16:23 +0100, pbrobinson(a)gmail.com wrote:
> 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.
The Bluez gdbus code is not available as a system library on any distro
as far as I know. Does Fedora happen to provide it?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
4389
days inactive
4390
days old
syncevolution@synevolution.org
8 comments
2 participants
participants (2)
-
Patrick Ohly -
pbrobinson＠gmail.com