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

Reply via email to