On Mon, 2010-05-31 at 13:38 +0100, Peter Robinson wrote:
> On Mon, May 31, 2010 at 1:19 PM, Patrick Ohly <[email protected]> wrote:
> > On Mon, 2010-05-31 at 12:48 +0100, Peter Robinson wrote:
> >> Firstly syncevolution doesn't compile against the latest evolution
> >> 2.31.x releases. I believe this is due to some changes in libcamel in
> >> preparation for evolution 3.0.
> >
> > SyncEvolution doesn't include anything from libcamel. Can you quote an
> > error message?
>
> Actually on closer look it might be changes in gtk and not evolution.
> My bad, sorry.
>
> http://koji.fedoraproject.org/koji/getfile?taskID=2210957&name=build.log
That points towards unistd.h:
sync-ui.c:2905: error: conflicting types for 'sync'
/usr/include/unistd.h:986: note: previous declaration of 'sync' was here
What is in line 986?
Please check the following patch. If it works, I'll include this in 1.0:
diff --git a/src/gtk-ui/sync-ui.c b/src/gtk-ui/sync-ui.c
index 40c9ceb..b693ec7 100644
--- a/src/gtk-ui/sync-ui.c
+++ b/src/gtk-ui/sync-ui.c
@@ -2928,7 +2928,7 @@ save_config (app_data *data, SyncevoSession
*session)
}
static void
-sync (operation_data *op_data, SyncevoSession *session)
+do_sync (operation_data *op_data, SyncevoSession *session)
{
GHashTable *source_modes;
GHashTableIter iter;
@@ -2998,7 +2998,7 @@ set_config_for_sync_cb (SyncevoSession *session,
return;
}
- sync (op_data, session);
+ do_sync (op_data, session);
}
static void
> I'll do so as best as I can. The following crash dumps look to be the
> most complete. If they don't have what's needed I'll look at what I
> can do to get you a more complete one.
>
> https://bugzilla.redhat.com/attachment.cgi?id=418008
> https://bugzilla.redhat.com/attachment.cgi?id=418102
> https://bugzilla.redhat.com/attachment.cgi?id=418228
All of that confirms that the "error" pointer wasn't set correctly. But
why? This needs to be checked with valgrind and gdb and looking at the
dbus library call prior to the failure.
--
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
