Hi Anssi! Thanks for the feedback. We can and should fix the binaries on syncevolution.org, and that depends on feedback like this. On Sat, 2010-04-24 at 12:25 +0100, Anssi Saari wrote: Does that have the effect of not finding the libraries at runtime, or are there other problems caused by this? All of the 64 bit binaries are from the same configure+make invocation and covered by the ensuing test run, only packaging these binaries is then done differently. Therefore we cannot easily change the path, but we could add /usr/lib to the hard-coded search path in executables and libs, which IMHO should fix the problem. That's strange. Evolution is installed? What does "syncevolution --version" say? I get: SyncEvolution 1.0beta3 using libedataserver-1.2.so.11 using libebook-1.2.so.9 using libecal-1.2.so.7 using libecal-1.2.so.7 using libbluetooth.so.3 Loading backend library /usr/lib/syncevolution/backends/syncmaemocal.so Loading backend library /usr/lib/syncevolution/backends/syncaddressbook.so Loading backend library /usr/lib/syncevolution/backends/syncecal.so Loading backend library /usr/lib/syncevolution/backends/syncebook.so Loading backend library /usr/lib/syncevolution/backends/syncfile.so Loading backend library /usr/lib/syncevolution/backends/syncsqlite.so Loading backend library /usr/lib/syncevolution/backends/syncxmlrpc.so Which version of libecal is in /usr/lib? The template files must be in /usr/share/syncevolution/templates/ (or whatever your datadir is in configure). I'm not familiar with stow. Are symlinks involved in /usr/local/share/syncevolution/templates after installation? Hmm, yes, the man page says so. I suspect that at one point during our template directory scanning, we trip over because find a symlink where a file is expected. This should work, though. Can you quote the complete "configure && make && stow" command line invocation that you used? I don't think so. -- 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.

On Sat, 2010-04-24 at 14:06 +0100, Anssi Saari wrote: That implies that dlopen("libecal-1.2.so.7") failed (picking just one example), for whatever reason. Let's compare notes. I my case: $ strace syncevolution --daemon=no --version 2>&1 | grep libecal open("/usr/lib/syncevolution/libecal-1.2.so.7", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/local/evolution/lib/libecal-1.2.so.7", O_RDONLY) = 6 using libecal-1.2.so.7 using libecal-1.2.so.7 I'm using a locally compiled Evolution, so that makes sense. $ LD_DEBUG=all syncevolution --daemon=no --version 2>&1 | grep libecal using libecal-1.2.so.7 using libecal-1.2.so.7 27559: calling fini: /usr/local/evolution/lib/libecal-1.2.so.7 [0] 27559: binding file /usr/local/evolution/lib/libecal-1.2.so.7 [0] to /lib/libc.so.6 [0]: normal symbol `__cxa_finalize' [GLIBC_2.2.5] LD_DEBUG is not very informative for dlopen(), so this is kind of expected. Did you use --enable-evolution-compatibility? You don't need that, linking against the libs directly is safe when compiling for ones own machine. We don't do it in the syncevolution.org binaries because that would limit compatibility more than necessary. This is on Debian, so I would expect /usr/lib to be in your dlopen() search path. Does setting LD_LIBRARY_PATH=/usr/lib make any difference? Could be, although that should only occur when you ran autogen.sh or autoconf. You can check that by looking up the definition of datadir in your src/Makefile, or in the binaries: $ strings -a /usr/lib/libsyncevolution.so.0 | grep /templates /usr/share/syncevolution/templates -- 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.

On Sun, 2010-04-25 at 09:45 +0100, Anssi Saari wrote: That points towards syncevo-dbus-server as the place where we need to look for the problem. Without --daemon=no, the relevant calls take place in syncevo-dbus-server. First test: run "syncevolution --daemon=yes --version", then check which syncevo-dbus-server is running. Is it really the one from the same installation as the command line tool? I think it is. So next, kill it and start it in a console with "strace" and "grep libecal". Does it show up? Yes. -- 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.

On Mon, 2010-04-26 at 08:47 +0100, Anssi Saari wrote: I can reproduce that. This is only a cosmetic issue, shouldn't affect real sessions. Fix will be in 1.0. Hmm, okay. So the only remaining problem is adding the search path for /usr/lib to SyncEvolution, right? I created an issue for it: http://bugs.meego.com/show_bug.cgi?id=1330 -- 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.