On 16/02/14 14:33, Ximin Luo wrote: > 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. >
Looking into this issue further, it is the case that plain icedove and its libxul.so do not have libldif60.so as a dependency (readelf --dynamic do not list it AFAICS), which could explain why it's not included in dependentlibs.list. However, m-g-k does for some reason: $ readelf --dynamic /usr/lib/xul-ext/gnome-keyring/platform/Linux_x86_64-gcc3/components/libgnomekeyring-icedove.so | grep ldif60 0x0000000000000001 (NEEDED) Shared library: [libldif60.so] I'm not doing anything special with the build process, so I am not sure why ldif60 is in there. I'm pretty sure m-g-k doesn't need it - I will see if I can build it without that dependency. But even if I tweak m-g-k like this, some questions still remain for icedove/thunderbird: - if (the thunderbird developers) expect that no-one needs ldif60, why keep it in the runtime directory? - OTOH, if they do expect that (an extension) might need it, why not include it in dependentlibs.list? There is no way for extensions to load it dynamically, AFAIK. 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
