On Mi, 2012-01-25 at 10:22 +0100, Murray Cumming wrote:
On Fri, 2012-01-13 at 17:09 +0100, Patrick Ohly wrote:
> On Do, 2012-01-05 at 16:55 +0100, Murray Cumming wrote:
> > As far as I can tell, this patch should be applied. Or is there some
> > reason to compile the code in dbus/ if --enable-dbus-service is not
> > used?
> For a while I compiled sync-ui and core SyncEvolution separately in
> MeeGo. In that case, D-Bus service is disabled and dbus/glib needs to be
> In other words, decoupling dbus compilation from D-Bus service
> compilation makes sense. But probably some of the current checks for
> what needs to be compiled inside dbus are not quite correct, because
> there is no real "enable/disable D-Bus" switch in configure.
I don't really understand. What is the dbus/ code used for if no
dbus-service is built or used?
It provides the D-Bus client libraries that could be used in combination
with a syncevo-dbus-service that was compiled separately. It's a bit
unusual to compile the same code twice; I had to do it in the past
because of the way how MeeGo was configured in OBS at the time (GTK not
part of the core OS).
We also noticed a relinking problem during make install, which is
by this commit:
It's already in the concurrent-sync-sessions branch, though this
URL will probably stop working after a future rebase:
I suggest that you put this in master.
Thanks, merged. I think I saw that once, but then couldn't reproduce,
probably because "make -j" happened to not trigger it all the time.
This is necessary because you install some libraries in
<prefix>/lib/syncevolution/ but other libraries in <prefix>/lib/ and
autotools is apparently not able to deal with that when relinking before
installing. Is there a good reason for installing some libraries in a
sub-directory. Simplifying that might let use remove some hacks from the
I've wondered about that myself recently. In the end I settled on adding
some hacks instead of moving the libs, mostly just because it was the
The original motivation was to avoid file clashes with other packages
also providing libgdbus.so. That alone wasn't enough, because later
symbols in that lib clashed with similarly named symbols in glib, so the
lib and all symbols were renamed.
I don't think there still is any reason to install normal libraries in
usr/lib/libsyncevolution. It should be used only for modules which get
dlopened(). Want to provide a patch?
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.