On 16/02/14 08:57, Carsten Schoenert wrote: > On Sat, Feb 15, 2014 at 07:46:17PM +0000, Ximin Luo wrote: >> (I assume 14 is a typo, you meant 24?) > > Indeed, of course. ;) > >> Perhaps a better fix would be to tweak the "intelligent" mechanism to >> be aware of /usr/lib/icedove, then. I can understand why upstream >> doesn't look here, since icedove is a Debian-specific name. This seems >> to me to be a better fix than to hard-code the path by -Wl,rpath, >> which AFAICS wasn't done before either (yet things still worked). > > Mhh, I don't think so, Why? > The intelligence isn't really a intelligence. The wrapper script simple > checks if the *.so file are symbolic links and if so set a LD_LIBRAY_PATH. > The code part inside the script /usr/lib/icedove/run-mozilla.sh is the > follwing part: > >> [snip] > > Currently I have no real idea how to tweek these lines to fix the issue > without > the usage of -Wl,rpath. If you have a hint, please let us know. On the > other side, the rpath option doesn't break any thing. >
I have found a much cleaner way to fix this. :) Simply insert "libldif60.so" before "libldap60.so" in /usr/lib/icedove/dependentlibs.list. It appears the order is important - for example, if you add it to the end of the file, icedove fails to start with "Couldn't load XPCOM". Actually, I don't think this version of icedove touches run-mozilla.sh at all. (In theory that file should even set LD_LIBRARY_PATH correctly, since it includes MOZ_DIST_BIN.) I'm not sure if this dependentlibs.list thing is an upstream bug - I can file one there too if you think it's appropriate. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
