Hello Ximin, I have CC'ed Mike, hopefully he can give us clearing answer.
On Sun, Feb 16, 2014 at 02:39:36PM +0000, Ximin Luo wrote: > >> 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.) Guido and myself talked today about that issue, we are asking ourself what in detail is now different from version 17? Why do we need now to set the LD_LIBRAY_PATH or set the option for RPATH. > > 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. We have to check the version 17 if there is the dependency inside that file, if so I think the version 24 has a bug on that. > 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. Thanks for figgering out this. @Mike Because you are deeper inside the whole source of Firefox/Thunderbird, do have a idea if the "issue" in the dependentlibs.list is a bug or do we something missing? Because we have to solve the RC bug depending on this bug report I think we can fix it in the first with the separate linker flag. And if this issue is related to an upstream bug we could get the transition to testing for the package Icedove* and related before Mozilla is releasing version 24.3.0+x. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
