12:24 p.m.
Hi,
I've been working on getting my dbus-server-reorganization branch on
par with master and I think I've almost achieved that. Currently they
are both seeing 3 failures and 2 errors. I see that the 2 errors are
probably addressed in bug #20990 as they start to appear only after
the recent autosync changes. The 3 failures seem to be due to issues
with the password property in temporary configs. I've pastebin'ed my
output in case it's helpful: http://pastebin.com/kRe0sPBK
I said "almost" on par because I've been having issues when building
with --disable-shared and --enable-static. When trying this I get an
error telling me to add -ldl to the LDFLAGS which I've done and it
does in fact seem to build correctly. However, with this, the backends
don't get registered and I, of course, get tons of problems when
running the tests. This issue exists in the first commit on my branch
which moved the dbus-server over to its own directory. However,
everything does seem to build and work fine with only --enable-static
specified which is what I've been using for running the tests.
Cheers,
Chris
7:22 p.m.
On Do, 2011-07-14 at 04:24 +0200, Chris Kühl wrote:
I've been working on getting my dbus-server-reorganization branch
on
par with master and I think I've almost achieved that. Currently they
are both seeing 3 failures and 2 errors. I see that the 2 errors are
probably addressed in bug #20990 as they start to appear only after
the recent autosync changes. The 3 failures seem to be due to issues
with the password property in temporary configs. I've pastebin'ed my
output in case it's helpful: http://pastebin.com/kRe0sPBK
'Method "GetReports" ... doesn't exist' is (partly?) fixed by:
commit f47d31580ddafa4a0243e809aa0ec5451e5182d3
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Tue Jul 12 12:46:47 2011 +0200
auto syncing: fix D-Bus API violations (part of BMC #20966)
Auto-sync sessions did not properly activate their D-Bus support and
thus couldn't be accessed via the Session D-Bus API. Must have
affected showing progress of such sessions in the GTK sync-ui.
They also weren't kept around for one minute, like the sessions
started by a client. Therefore UIs which need to retrieve information
about a completed session failed for a second reason.
Fixed by adding the necessary "activate()" and use "addTimeout()"
trick for session expiry also in the AutoSyncManager. The later was
moved into DBusServer for that.
I'm not sure whether the fix is complete, because I still see the
failure in the nightly testing, in a slightly different way than locally
(where I cannot reproduce it anymore):
http://runtests.syncevolution.org/2011-07-13-19-56_dist/head-lucid-amd64/...
http://runtests.syncevolution.org/2011-07-13-19-56_dist/head-lucid-amd64/...
[DEBUG 00:00:01] session /org/syncevolution/Session/17312472401310560063
deconstructing
process 28897: arguments to dbus_connection_get_data() were incorrect, assertion
"connection != NULL" failed in file dbus-connection.c line 5797.
This is normally a bug in some application using the D-Bus library.
Adding the auto sync tests broke some other tests, which I only noticed
in that nightly testing. Fixed by:
commit 811d10fc33f64a46ae43ce3903d637cad02c15f0
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed Jul 13 15:54:49 2011 +0200
D-Bus testing: avoid test failures due to GNOME keyring side effects
The auto-sync tests modified the GNOME keyring by setting a password
for the same URL that is also used in the password request tests,
which caused those tests to fail.
Ideally this would be fixed by running each test with a fresh GNOME
keyring, but this is hard to set up. Instead solve the problem by
keeping the URLs separate.
I said "almost" on par because I've been having issues
when building
with --disable-shared and --enable-static. When trying this I get an
error telling me to add -ldl to the LDFLAGS which I've done and it
does in fact seem to build correctly. However, with this, the backends
don't get registered and I, of course, get tons of problems when
running the tests. This issue exists in the first commit on my branch
which moved the dbus-server over to its own directory. However,
everything does seem to build and work fine with only --enable-static
specified which is what I've been using for running the tests.
Did you notice the rules which add the backend's *Register.cpp files to
the syncevo-dbus-server?
src/Makefile.am (generated from Makefile-gen.am) contains:
BACKEND_REGISTRIES = ... backends/.../*Register.cpp
This is then added to syncevo-dbus-server via:
CORE_SOURCES += $(BACKEND_REGISTRIES)
syncevo_dbus_server_SOURCES = \
...
$(CORE_SOURCES)
The easiest solution might be to keep linking the main
syncevo-dbus-server in "src", but with all code compiled in a
sub-directory into a helper library.
--
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.
12:14 a.m.
> I said "almost" on par because I've been having
issues when building
> with --disable-shared and --enable-static. When trying this I get an
> error telling me to add -ldl to the LDFLAGS which I've done and it
> does in fact seem to build correctly. However, with this, the backends
> don't get registered and I, of course, get tons of problems when
> running the tests. This issue exists in the first commit on my branch
> which moved the dbus-server over to its own directory. However,
> everything does seem to build and work fine with only --enable-static
> specified which is what I've been using for running the tests.
Did you notice the rules which add the backend's *Register.cpp files to
the syncevo-dbus-server?
src/Makefile.am (generated from Makefile-gen.am) contains:
BACKEND_REGISTRIES = ... backends/.../*Register.cpp
This is then added to syncevo-dbus-server via:
CORE_SOURCES += $(BACKEND_REGISTRIES)
syncevo_dbus_server_SOURCES = \
...
$(CORE_SOURCES)
Yes, I've got that in my src/dbus-server/Makefile-gen.am. In fact,
that's why I had to use the "-gen." That appears to give me what I
need in the generated Makefile.am but maybe I'm fumbling something.
The easiest solution might be to keep linking the main
syncevo-dbus-server in "src", but with all code compiled in a
sub-directory into a helper library.
I attempted this but had the same results. Here is the patch I tried:
http://pastebin.com/L8BKtY7Z
Does that look like what you had in mind?
Cheers,
Chris
12:37 a.m.
On Do, 2011-07-14 at 16:14 +0200, Chris Kühl wrote:
>> I said "almost" on par because I've been
having issues when building
>> with --disable-shared and --enable-static. When trying this I get an
>> error telling me to add -ldl to the LDFLAGS which I've done and it
>> does in fact seem to build correctly. However, with this, the backends
>> don't get registered and I, of course, get tons of problems when
>> running the tests. This issue exists in the first commit on my branch
>> which moved the dbus-server over to its own directory. However,
>> everything does seem to build and work fine with only --enable-static
>> specified which is what I've been using for running the tests.
>
> Did you notice the rules which add the backend's *Register.cpp files to
> the syncevo-dbus-server?
>
> src/Makefile.am (generated from Makefile-gen.am) contains:
> BACKEND_REGISTRIES = ... backends/.../*Register.cpp
>
> This is then added to syncevo-dbus-server via:
> CORE_SOURCES += $(BACKEND_REGISTRIES)
> syncevo_dbus_server_SOURCES = \
> ...
> $(CORE_SOURCES)
>
Yes, I've got that in my src/dbus-server/Makefile-gen.am. In fact,
that's why I had to use the "-gen." That appears to give me what I
need in the generated Makefile.am but maybe I'm fumbling something.
> The easiest solution might be to keep linking the main
> syncevo-dbus-server in "src", but with all code compiled in a
> sub-directory into a helper library.
>
I attempted this but had the same results. Here is the patch I tried:
http://pastebin.com/L8BKtY7Z
Does that look like what you had in mind?
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.
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.
I was undecided whether I should use hyphens in the library name. The
other libraries don't use the, so I decided against it. Admittedly makes
it harder to read.
Speaking of naming, should src/dbus-server rather be src/dbus/server? It
would be more consistent with "anything related to SyncEvolution D-Bus
in dbus". Also plays nicer with tab completion of file names in the
shell. I often ended up with dbus<tab><return> taking me to the
"dbus"
directory instead of completing to "dbus-server".
--
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.
11:30 p.m.
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:
> >> I said "almost" on par because I've been having issues when
building
> >> with --disable-shared and --enable-static. When trying this I get an
> >> error telling me to add -ldl to the LDFLAGS which I've done and it
> >> does in fact seem to build correctly. However, with this, the backends
> >> don't get registered and I, of course, get tons of problems when
> >> running the tests. This issue exists in the first commit on my branch
> >> which moved the dbus-server over to its own directory. However,
> >> everything does seem to build and work fine with only --enable-static
> >> specified which is what I've been using for running the tests.
> >
> > Did you notice the rules which add the backend's *Register.cpp files to
> > the syncevo-dbus-server?
> >
> > src/Makefile.am (generated from Makefile-gen.am) contains:
> > BACKEND_REGISTRIES = ... backends/.../*Register.cpp
> >
> > This is then added to syncevo-dbus-server via:
> > CORE_SOURCES += $(BACKEND_REGISTRIES)
> > syncevo_dbus_server_SOURCES = \
> > ...
> > $(CORE_SOURCES)
> >
>
> Yes, I've got that in my src/dbus-server/Makefile-gen.am. In fact,
> that's why I had to use the "-gen." That appears to give me what I
> need in the generated Makefile.am but maybe I'm fumbling something.
>
> > The easiest solution might be to keep linking the main
> > syncevo-dbus-server in "src", but with all code compiled in a
> > sub-directory into a helper library.
> >
>
> I attempted this but had the same results. Here is the patch I tried:
> http://pastebin.com/L8BKtY7Z
>
> Does that look like what you had in mind?
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.
======================================================================
ERROR: testCredentialsRight (__main__.TestConnection)
TestConnection.testCredentialsRight - send correct credentials
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/chris/checkout/meego/syncevolution/test/test-dbus.py",
line 2258, in testCredentialsRight
self.setupConfig()
File "/home/chris/checkout/meego/syncevolution/test/test-dbus.py",
line 2151, in setupConfig
self.session.SetConfig(False, False, self.config, utf8_strings=True)
File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 140, in
__call__
**keywords)
File "/usr/lib/python2.7/site-packages/dbus/connection.py", line
630, in call_blocking
message, timeout)
DBusException: org.syncevolution.InvalidCall: invalid value 'file' for
property 'backend': 'not one of the valid values (virtual, calendar =
events, addressbook = contacts, todo = tasks, memo = memos = notes)'
I'm assuming this was working for you so I'm not sure what's going on on my
end.
Like I said I still like the change so I'll merge it into my branch.
I was undecided whether I should use hyphens in the library name.
The
other libraries don't use the, so I decided against it. Admittedly makes
it harder to read.
Speaking of naming, should src/dbus-server rather be src/dbus/server? It
would be more consistent with "anything related to SyncEvolution D-Bus
in dbus". Also plays nicer with tab completion of file names in the
shell. I often ended up with dbus<tab><return> taking me to the
"dbus"
directory instead of completing to "dbus-server".
Sure, I'll do this. I think I'll also remove the 'syncevo-' from the
syncevo-dbus-server.* and syncevo-exceptions.* files but leave it on
the executable to be consistent with the other executables.
Cheers,
Chris
1:31 a.m.
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
*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.
--
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.
9:51 p.m.
On Thu, 2011-07-14 at 04:24 +0200, Chris Kühl wrote:
[snip]
I've been having issues when building
with --disable-shared and --enable-static. When trying this I get an
error telling me to add -ldl to the LDFLAGS which I've done and it
does in fact seem to build correctly. However, with this, the backends
don't get registered
[snip]
Maybe we need a simple unit test (for make check) that checks that the
backends are registered. That would help us to fix this and make sure
that it doesn't come back.
--
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
10:26 p.m.
On Mo, 2011-07-25 at 13:51 +0200, Murray Cumming wrote:
On Thu, 2011-07-14 at 04:24 +0200, Chris Kühl wrote:
[snip]
> I've been having issues when building
> with --disable-shared and --enable-static. When trying this I get an
> error telling me to add -ldl to the LDFLAGS which I've done and it
> does in fact seem to build correctly. However, with this, the backends
> don't get registered
[snip]
Maybe we need a simple unit test (for make check) that checks that the
backends are registered. That would help us to fix this and make sure
that it doesn't come back.
Define "the backends" :-/ That list depends on configure options and who
is compiling SyncEvolution. Some people have additional backends in
their source tree. This complication is the reason why there is no such
test in client-test at the moment.
A unit test might be able to check that some well-known backends (like
the file backend) is listed, but anything beyond that is difficult. It
would have caught this issue, though.
--
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.
12:58 a.m.
On Mon, 2011-07-25 at 14:26 +0200, Patrick Ohly wrote:
On Mo, 2011-07-25 at 13:51 +0200, Murray Cumming wrote:
> On Thu, 2011-07-14 at 04:24 +0200, Chris Kühl wrote:
> [snip]
> > I've been having issues when building
> > with --disable-shared and --enable-static. When trying this I get an
> > error telling me to add -ldl to the LDFLAGS which I've done and it
> > does in fact seem to build correctly. However, with this, the backends
> > don't get registered
> [snip]
>
> Maybe we need a simple unit test (for make check) that checks that the
> backends are registered. That would help us to fix this and make sure
> that it doesn't come back.
Define "the backends" :-/ That list depends on configure options and who
is compiling SyncEvolution. Some people have additional backends in
their source tree. This complication is the reason why there is no such
test in client-test at the moment.
At the least there can be a test that there is at least one backend.
Also, maybe we can test for the expected backends based on the configure
options?
A unit test might be able to check that some well-known backends
(like
the file backend) is listed, but anything beyond that is difficult. It
would have caught this issue, though.
Yes, I think it would be useful.
--
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
6:48 p.m.
On Mon, 2011-07-25 at 16:58 +0200, Murray Cumming wrote:
At the least there can be a test that there is at least one backend.
Also, maybe we can test for the expected backends based on the
configure
options?
> A unit test might be able to check that some well-known backends
(like
> the file backend) is listed, but anything beyond that is difficult.
It
> would have caught this issue, though.
Yes, I think it would be useful.
This patch adds a "make check" test that just checks whether
SyncSource::backendsInfo() is an empty string. Obviously, we would want
to add more specific API than just backendsInfo() to check for specific
backends.
However, I've added an ifdef there because, of course, we should expect
that to be empty when ENABLE_MODULES is not defined (when using
--disable-shared), because the SyncSource code checks for that:
https://meego.gitorious.org/meego-middleware/syncevolution/blobs/dbus-ser...
So I guess this isn't really a test case for the problem that you are
discussing. What "backends" _should_ be available when using
--disable-shared? And is every backend a source backend?
--
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
8:07 p.m.
On Di, 2011-07-26 at 10:48 +0200, Murray Cumming wrote:
On Mon, 2011-07-25 at 16:58 +0200, Murray Cumming wrote:
>
> At the least there can be a test that there is at least one backend.
>
> Also, maybe we can test for the expected backends based on the
> configure
> options?
>
> > A unit test might be able to check that some well-known backends
> (like
> > the file backend) is listed, but anything beyond that is difficult.
> It
> > would have caught this issue, though.
>
> Yes, I think it would be useful.
This patch adds a "make check" test that just checks whether
SyncSource::backendsInfo() is an empty string. Obviously, we would want
to add more specific API than just backendsInfo() to check for specific
backends.
Tests in SyncEvolution should better be written using the existing
CppUnit-based unit and integration testing.
For a simple example, see util.cpp and
SYNCEVOLUTION_TEST_SUITE_REGISTRATION(TimespecTest);
SyncEvolution has some unit tests, but not that many. I find it more
important to have good integration/interoperability testing.
The problem with not registering the backends would have shown up there,
if the tests had been run on a platform exhibiting the problem. So a
simpler unit test would have been nice, but not essential.
--
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.
8:27 p.m.
On Tue, 2011-07-26 at 12:07 +0200, Patrick Ohly wrote:
The problem with not registering the backends would have shown up
there,
if the tests had been run on a platform exhibiting the problem. So a
simpler unit test would have been nice, but not essential.
So where is this problem showing up now?
--
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
11:02 p.m.
On Di, 2011-07-26 at 12:27 +0200, Murray Cumming wrote:
On Tue, 2011-07-26 at 12:07 +0200, Patrick Ohly wrote:
>
> The problem with not registering the backends would have shown up
> there,
> if the tests had been run on a platform exhibiting the problem. So a
> simpler unit test would have been nice, but not essential.
So where is this problem showing up now?
The problem is not in the master branch and thus doesn't show up in the
nightly testing.
--
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.
11:13 p.m.
On Tue, 2011-07-26 at 15:02 +0200, Patrick Ohly wrote:
> > The problem with not registering the backends would have
shown up
> > there,
> > if the tests had been run on a platform exhibiting the problem. So
a
> > simpler unit test would have been nice, but not essential.
>
> So where is this problem showing up now?
The problem is not in the master branch and thus doesn't show up in
the
nightly testing.
Chris, I was trying this with your dbus-server-reorganization branch.
Maybe you could apply my patch locally and investigate. I can't get my
test to fail ever.
--
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
11:51 p.m.
On Di, 2011-07-26 at 15:13 +0200, Murray Cumming wrote:
On Tue, 2011-07-26 at 15:02 +0200, Patrick Ohly wrote:
> > > The problem with not registering the backends would have shown up
> > > there,
> > > if the tests had been run on a platform exhibiting the problem. So
> a
> > > simpler unit test would have been nice, but not essential.
> >
> > So where is this problem showing up now?
>
> The problem is not in the master branch and thus doesn't show up in
> the
> nightly testing.
Chris, I was trying this with your dbus-server-reorganization branch.
Maybe you could apply my patch locally and investigate. I can't get my
test to fail ever.
The root cause for the failure in that branch is understood, I just need
the time to fix it. It only triggers when using static linking.
See
From: Patrick Ohly <patrick.ohly(a)intel.com>
To: Chris Kühl <blixtra(a)gmail.com>
Cc: SyncEvolution <syncevolution(a)syncevolution.org>
Subject: Re: [SyncEvolution] dbus-server-reorganization progress
Date: Mon, 18 Jul 2011 17:31:55 +0200
...
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
...
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.
--
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.
12:11 a.m.
On Tue, 2011-07-26 at 15:51 +0200, Patrick Ohly wrote:
The root cause for the failure in that branch is understood, I just
need
the time to fix it. It only triggers when using static linking.
OK. I thought I might fix it myself if I could reproduce it with a
simple test case.
I'll make a cppunit version of the patch anyway.
--
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
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.
9:45 a.m.
On Tue, Jul 26, 2011 at 5:39 PM, Patrick Ohly <patrick.ohly(a)intel.com> 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 <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'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
5:07 p.m.
On Mi, 2011-07-27 at 01:45 +0200, Chris Kühl wrote:
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.
Just to be sure, you mean the "no backends available in static
compilation" problem?
The last commit fixed it for me. Anyway, the little benefit of compiling
the source files less often is not worth the hassle. I'll revert to
including the core source files in all executables.
--
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.
4071
days inactive
4084
days old
syncevolution@synevolution.org
18 comments
3 participants
participants (3)
-
Chris Kühl -
Murray Cumming -
Patrick Ohly