Re: [SyncEvolution] compiling 0.9 on F-11 and rawhide

>> 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? Nope. Just a plain ./configure and then a make :)

>> 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. Yes, that looks like it. I get the following below when compiling it as before (it worked fine in beta3).

The standard fix for this in Fedora is to run the following 2 sed commands which generally fixes the problem. Apparently in this case it doesn't :-) sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool