Skip to content

SyncEvolution for ITOS2008: Compiled, But Runs Into D-Bus Timeouts

I have checked why the SyncEvolution binary for ITOS2005/2006/2007 does not run on the new ITOS2008 of the Nokia N810. As I mentioned already, the syncebook.so contains dependencies on libraries which no longer exist. But these libraries are not called by SyncEvolution itself, only by the libs that SyncEvolution uses, and therefore these unsatisfied dependencies can be avoided. I did that (details below), only to find that the old issue with premature D-Bus timeouts seems to be back.

Compilation

For those who want to know, the extra dependencies could be avoided by:

  1. compiling with LDFLAGS=-Wl,--as-needed
  2. patching libtool so that it puts that flag at the right place when building syncebook.so

The second point warrants an explanation: when libtool 1.5.24 (and probably other versions, too) sees -Wl on the command line, it adds this flags to its compiler_flags variable. This variable is inserted at the beginning of the gcc command line when building executables, but at the end when building libraries like syncebook.so. -Wl,--as-needed only has an effect for libraries specified after it on the command line, so it was useless for syncebook.so. I don’t know the rationale for inserting the compiler_flags at different places; my current workaround is to patch the libtool script as part of the package build rules so that it always comes at the beginning and that seems to work fine. The exact command for that is:

perl -pi -e ’s/-shared (.*) \\\$compiler_flags/-shared \\\$compiler_flags $1/’ libtool

D-Bus Timeouts

Unfortunately the resulting binary does not work reliably. I have seen an unspecified segfault (unfortunately I didn’t capture a stack back trace) and the following errors from inside the libebook/D-Bus libraries:

21:39:15 GMT +0000 [ERROR] – addressbook: reading items to be deleted: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

process 3549: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details.
Most likely, the application called unref() too many times and removed a reference belonging to libdbus, since this is a shared connection.
D-Bus not built with -rdynamic so unable to print a backtrace

The first error comes from the implementation of e_book_get_contacts() with the query e_book_query_vcard_field_exists("X-OSSO-CONTACT-STATE"). It looks suspiciously like the premature timeouts that I worked around on ITOS2005/2006/2007 by using a patched libdbus. I need to check whether that workaround still has the desired effect, but because I’ll go on a one-week vacation tomorrow don’t hold your breath :-/

{ 1 } Trackback

  1. [...] have implemented a better workaround for the D-Bus timeout problems which affected the recompiled SyncEvolution for the N810: instead of linking a patched libdbus into the binary, the binary now contains a wrapper for one [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *