On 14/02/14 10:09, Carsten Schoenert wrote: > Hello Ximin, > > On Wed, Feb 12, 2014 at 04:00:47PM +0000, Ximin Luo wrote: >> All extensions are from the Debian repos. Actually I have disabled >> everything except moz-g-k and the bug is still present. I'm not sure >> how another extension could interfere with where icedove loads its >> libs from. > > O.k. just want to be sure that no other installed software will causes > some trouble. > >> I repeat, setting LD_LIBRARY_PATH=/usr/lib/icedove makes things work. >> Perhaps you just forgot a -Wl,rpath during the build process? > > Mozilla has changed the starting wrapper for Thunderbird in version 14 > or so. They use some kind of "intelligent" mechanism to detect the used > librarys and set a LD_LIBRARY_PATH if needed. > But this covers just a included directory 'plugins/' and not > /usr/lib/icedove. >
(I assume 14 is a typo, you meant 24?) 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). > So you propably right with the linker flag '-Wl,rpath". I rebuild > yesterday the current version 24.3.0 with this additional declaration to > LDFLAGS. > I uploaded the packages with this little change to > > http://openmct.org/misc/icedove24-test/ > Thanks - could I ask you to sign the changes file so I can verify what I'm installing? > I checked the builded binary 'icedove' with readelf. The binarys now > uses RUNPATH. > >> (pbuilder)root@jessie:~/icedove-24.3.0/debian/tmp/usr/lib/icedove# readelf >> --dynamic icedove | grep PATH >> 0x000000000000001d (RUNPATH) Library runpath: [/usr/lib/icedove] > > So I'd like to ask you if you please can test once again the Icedove > package with mozilla-gnome-keyring? > Unfortunately I never have used m-g-k and I'm having currently not much > time and testing installations to play with m-g-k. I think you know your > package much better then me and will find much quicker if it works > correctly with this changes while the build process. > This is an issue with icedove and not m-g-k though. I can only test, but I cannot attempt to fix it, since I'm not familiar with the icedove build system. You don't need to "know" m-g-k - it just helps you to verify that the bug is fixed, by confirming the absence of the "failed to load [..] .so" error message. You don't need to use m-g-k at all, you don't need to change any settings. >> Here are the messages from icedove console: >> >> Could not read chrome manifest >> 'file:///usr/lib/icedove/components/components.manifest'. > > This should be also fixed in the packages from above. We have forgotten > to change the install declarations for this directory. Mozilla has added > the manifest file between version 17 and 24. > >> Failed to load native module at path >> '/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{6f9d85e0-794d-11dd-ad8b-0800200c9a66}/platform/Linux_x86_64-gcc3/components/libgnomekeyring-icedove.so': >> (80004005) libldif60.so: cannot open shared object file: No such file or >> directory >> Could not read chrome manifest >> 'file:///usr/lib/icedove/extensions/%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D/chrome.manifest'. >> While creating services from category 'profile-after-change', could not >> create service for entry 'Disk Space Watcher Service', contract ID >> '@mozilla.org/toolkit/disk-space-watcher;1' >> >> Feel free to install xul-ext-gnome-keyring and play with it yourself. > > Thanks for your interaction. > -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
