On Tue, 2009-10-20 at 14:01 +0100, Peter Robinson wrote:
Hi Patrick,
On Tue, Oct 20, 2009 at 1:20 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> Hello!
>
> For those of you running the 0.9.1 beta announced last week, please
> update to beta 2. The bug hunt is still on, so please test and provide
> feedback...
I'm having issues building this on Fedora 12. The error looks like it
should be able to install into a build root environment but it seems
there's an issue with the check. I had the same issue with beta1 but
0.9.0 builds fine.
We changed the way how the backends are installed:
commit 35ee63661949243bfb4bc00afd33b5d68489975d
Author: Chen Congwu <congwu.chen(a)intel.com>
Date: Wed Sep 2 11:13:10 2009 +0800
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable
backends
Install head files to a standard path, the remaining dependencies are
synthesis and boost
client-test is portable when ENABLE_MODULES is defined, no longer link to
backends libraries.
Add --enable-developer-mode, in which mode the backend scan path will be
under current build directory for development purposes.
...
diff --git a/src/backends/evolution/Makefile.am b/src/backends/evolution/Makefile.am
index 997349c..23bf672 100644
--- a/src/backends/evolution/Makefile.am
+++ b/src/backends/evolution/Makefile.am
@@ -1,11 +1,11 @@
...
if ENABLE_MODULES
-pkglib_LTLIBRARIES = $(SYNCSOURCES)
+backend_LTLIBRARIES = $(SYNCSOURCES)
Congwu, do you remember why backend_ instead of pkglib_ is better? Any
idea for solving this issue on Fedora 12?
Peter, does the problem perhaps go away when running "./autogen.sh" in
the SyncEvolution source directory and then reconfiguring/recompiling?
Which version of libtool do you have on Fedora 12? Finally, do the .rpms
provided on
syncevolution.org work on Fedora 12?
I definitely want to solve this problem, but it is equally important to
know whether providing the .rpms is worthwhile.
--
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.