Re: [SyncEvolution] compiling 0.9 on F-11 and rawhide
On Sun, 2009-08-16 at 14:10 +0100, Peter Robinson wrote:
I'm having a few issues compiling the syncevolution 0.9 release
on
either F-11 or rawhide.
I'm not sure if its a missing dep that isn't picked up by ./configure
or something else. The last beta compiled OK so I suspect its
something quite minor that I've missed.
I'm not aware of build changes in the SyncEvolution and libsynthesis
source since the last beta. Perhaps comparing against a build of that on
your system will give a clue?
You are compiling both in exactly the same way, I presume? The paths
below (syncevolution-0.9/src/build-synthesis/src) indicate that you
compile from source .tar.gz. Did you rebuild libtool and friends?
I get the following undefined
reference errors below.
The root problem of those is that libsynthesis.so.0 is not found:
/bin/sh ../libtool --tag=CXX --mode=link g++
-I/home/perobinson/rpmbuild/BUILD/syncevolution-0.9/src/build-synthesis/src
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-uSyncEvolution_Module_Version -Wl,--export-dynamic -o syncevolution
syncevolution-syncevolution.o syncevolution-test.o
core/libsyncevolution.la -lglib-2.0
mkdir .libs
DIE_RPATH_DIE="/usr/lib64/syncevolution:$DIE_RPATH_DIE" g++
-I/home/perobinson/rpmbuild/BUILD/syncevolution-0.9/src/build-synthesis/src
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-uSyncEvolution_Module_Version -Wl,--export-dynamic -o
.libs/syncevolution syncevolution-syncevolution.o syncevolution-test.o
core/.libs/libsyncevolution.so -lglib-2.0
/usr/bin/ld: warning: libsynthesis.so.0, needed by
core/.libs/libsyncevolution.so, not found (try using -rpath or
-rpath-link)
I suspect that wiping out -rpath inside core/.libs/libsyncevolution.so
too aggressively is causing this. But this is just a guess.
--
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.