1:39 a.m.
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> 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 think it'll be cleaner to go back to compiling the common source files
separately for all executables in src, as it is currently done in the
master branch.
--
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.