On Di, 2011-08-23 at 09:33 +0000, Woodhouse, David wrote:
> On Tue, 2011-08-23 at 08:49 +0200, Patrick Ohly wrote:
> > Found it. stracing the final ld invocation shows that it looks at an old
> > libeasaccount.so.0 in my /tmp/activesyncd install dir. Wiping that out
> > first avoided the issue.
> >
> > I still don't know why ld considers those old libs at all. Does setting
> > the rpath have that effect? That is the only reference
> > to /tmp/activesyncd/lib.
>
> It's more likely to be the rpath in libeas.so itself, rather than on the
> command line.
This is the rpath:
0x000000000000000f (RPATH) Library rpath:
[/usr/local/evolution-2.32-2011-07-05/lib:/home/pohly/work/activesyncd/libeasaccount/src/.libs:/home/pohly/work/activesyncd/libeassync/src/.libs:/tmp/activesyncd/lib:/usr/local/libwbxml-0.11.0/lib]
It does contain the install directory, but so is the build directory,
and ldd did find the right library:
$ ldd /home/pohly/work/activesyncd/eas-daemon/libeas/.libs/libeas.so | grep
account
libeasaccount.so.0 =>
/home/pohly/work/activesyncd/libeasaccount/src/.libs/libeasaccount.so.0
(0x00007f02a9fa4000)
No idea why ld doesn't. Shrug.
> I'm surprised that libtool would put that rpath into the libraries
> during the initial build; did you configure with --enable-fast-install?
No.
> Personally I always install using symlinks (the trick documented at
> http://www.advogato.org/person/dwmw2/diary/219.html ) so I never get
> stale libraries installed or have to remember to run 'make install'
> after building, so I didn't see this problem.
Nice trick.
--
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
