Re: [SyncEvolution] dbus-server-reorganization progress

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 <patrick.ohly(a)intel.com&gt; 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).