On Tue, Jul 26, 2011 at 5:39 PM, Patrick Ohly <[email protected]> wrote: > On Mo, 2011-07-18 at 17:31 +0200, Patrick Ohly wrote: >> On Mo, 2011-07-18 at 15:30 +0200, Chris Kühl wrote: >> > On Fri, Jul 15, 2011 at 4:37 PM, Patrick Ohly <[email protected]> >> > wrote: >> > > On Do, 2011-07-14 at 16:14 +0200, Chris Kühl wrote: >> > > No, not quite. I wanted to avoid the need for the -gen.am trick in >> > > src/dbus-server by linking the syncevo-dbus-server in src, as before. >> > > >> > >> > Ok, good. Having a Makefile-gen.am in src/dbus-server just for the >> > backends always felt wrong to me anyway. >> > >> > > I checked out your branch and, after I couldn't figure out why autotools >> > > didn't link the registry files into syncevo-dbus-server, implemented my >> > > proposal. Have a look at dbus-server-reorganization-pohly. >> > > >> > > It starts with a commit which combines all the registry files into an >> > > utility library. Adding them as source to each executable was just plain >> > > laziness. >> > > >> > > Then the revised "move to dbus-server" patch adds a >> > > libsyncevodbusserver.la utility library in src/dbus-server which is used >> > > to link syncevo-dbus-server in src. >> > > >> > >> > Unfortunately, I'm still getting the same issue. Here is the first error I >> > get. >> [...] >> > I'm assuming this was working for you so I'm not sure what's going on on >> > my end. >> >> I must admit that I pushed my proposal without enough testing. Oops. >> >> What's probably happening is this: >> * the register classes are now all in a .a lib >> * nothing depends on these object files when linking the executables >> * they don't get into the executables > > That was indeed it. > >> *This* and not laziness in defining the rules must have been the reason >> why previously, these classes were listed as source files of all >> executables. The resulting object files are then always linked into the >> executable. >> >> I'll check whether there is an easy fix. If not, then we'll have to go >> back to compiling the sources files multiple times. > > ld's --whole-archive option is what we need. The only problem is that > libtool "helpfully" reorders command line options it so that > -Wl,--whole-archive -Wl,--no-whole-archive no longer wraps around. > libsynccommon.la. > > Here's a potential solution: > > $ git diff > diff --git a/src/Makefile-gen.am b/src/Makefile-gen.am > index 11bff8f..c47064a 100644 > --- a/src/Makefile-gen.am > +++ b/src/Makefile-gen.am > @@ -132,11 +132,11 @@ endif > # SYNCEVOLUTION_LDADD will be replaced with > libsyncebook.la/libsyncecal.la/libsyncsqlite.la > # if linking statically against them, empty otherwise; > # either way this does not lead to a dependency on those libs - done > explicitly > -syncevolution_LDADD = libsyncevocommon.la $(CORE_LDADD) $(KEYRING_LIBS) > $(KDE_KWALLET_LIBS) > +syncevolution_LDADD = $(CORE_LDADD) $(KEYRING_LIBS) $(KDE_KWALLET_LIBS) > if COND_DBUS > syncevolution_LDADD += gdbus/libgdbussyncevo.la > endif > -syncevolution_LDFLAGS = $(CORE_LD_FLAGS) $(DBUS_LIBS) > +syncevolution_LDFLAGS = -Wl,--whole-archive -Wl,.libs/libsyncevocommon.a > -Wl,--no-whole-archive $(CORE_LD_FLAGS) $(D > syncevolution_CXXFLAGS = $(SYNCEVOLUTION_CXXFLAGS) $(CORE_CXXFLAGS) > $(KEYRING_CFLAGS) -I$(srcdir)/gdbus $(DBUS_CFLAG > syncevolution_DEPENDENCIES = $(EXTRA_LTLIBRARIES) $(CORE_DEP) > libsyncevocommon.la # $(SYNTHESIS_DEP) > > This is a hack. It completely circumvents the usual libtool logic and > makes assumptions about libtool internals (.libs dir). >
I've tried my dbus-server-reorg branch with this change as well as your dbus-server-reorg-pohly-libsynccommon branch but I still get the same results as before. Btw, I've got some basic code in the bluetooth-device-id branch that extracts the PnPInformation. But we can have that discussion in Bugzilla. Cheers, Chris _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
