Comment 44 for bug 899858

I was going to use a ppa, but since I'm still figuring out launchpad I couldn't get it to accept the changes file I was using. I think I have figured out the problem and I'll use that in a future.

The fix is right, because it fixes the problem, and so far we can consistently reproduce the problem on any version of gvfs that has 05_shared_libdaemon.patch . We have not seen the problem on any package without the patch, and removing the patch fixes the problem, so there is a strong correlation there. Any explanation as to why the patch breaks things or what other issues might crop up from statically linking is speculation at this point, no one has root caused the problem. Though I have no reason to suspect statically linking again will produce any problems, since upstream does it and we did it in 11.04 and previous releases. We are currently looking in to the root cause.

A summary of what we know so far because this report is getting long: In 2009 the patch was introduced in version 1.4.1-5+gdu, but only in Debian sid. I haven't tested but I suspect that version also suffers from the regression. The patch was not submitted upstream, and the upstream version was never affected. In Ubuntu, with version gvfs-1.8.0-1 (which I have tested) we rebased to the branch that includes the patch. The Ubuntu 11.04 release was able to browse using gvfs. The latest version there is 1.8.0-0ubuntu3. In 11.10, we hit this regression where you can't browse obex, as result of the rebase to the sid branch. I've raised the bug in Debian as well.

To be sure, the savings we get from shared objects is pretty large. Here is the dir size statically linked:
# du -sh /usr/lib/gvfs
3.7M /usr/lib/gvfs

and shared:
 du -sh /usr/lib/gvfs
1.6M /usr/lib/gvfs

As I said earlier we're currently figuring out the root cause.