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:
> ##
> ## Set LD_LIBRARY_PATH
> ##
> ## On Solaris we use $ORIGIN (set in RUNPATH) instead of LD_LIBRARY_PATH
> ## to locate shared libraries.
> ##
> ## When a shared library is a symbolic link, $ORIGIN will be replaced with
> ## the real path (i.e., what the symbolic link points to) by the runtime
> ## linker. For example, if dist/bin/libxul.so is a symbolic link to
> ## toolkit/library/libxul.so, $ORIGIN will be "toolkit/library" instead of
> "dist/bin".
> ## So the runtime linker will use "toolkit/library" NOT "dist/bin" to locate
> the
> ## other shared libraries that libxul.so depends on. This only happens
> ## when a user (developer) tries to start firefox, thunderbird, or seamonkey
> ## under dist/bin. To solve the problem, we should rely on LD_LIBRARY_PATH
> ## to locate shared libraries.
> ##
> ## Note:
> ## We test $MOZ_DIST_BIN/*.so. If any of them is a symbolic link,
> ## we need to set LD_LIBRARY_PATH.
> ##########################################################################
> moz_should_set_ld_library_path()
> {
> [ `uname -s` != "SunOS" ] && return 0
> for sharedlib in $MOZ_DIST_BIN/*.so
> do
> [ -h $sharedlib ] && return 0
> done
> return 1
> }
> if moz_should_set_ld_library_path
> then
>
> LD_LIBRARY_PATH=${MOZ_DIST_BIN}:${MOZ_DIST_BIN}/plugins:${MRE_HOME}${LD_LIBRARY_PATH:+":$LD_LIBRARY_PATH"}
> fi
>
> if [ -n "$LD_LIBRARYN32_PATH" ]
> then
>
> LD_LIBRARYN32_PATH=${MOZ_DIST_BIN}:${MOZ_DIST_BIN}/plugins:${MRE_HOME}${LD_LIBRARYN32_PATH:+":$LD_LIBRARYN32_PATH"}
> fi
> if [ -n "$LD_LIBRARYN64_PATH" ]
> then
>
> LD_LIBRARYN64_PATH=${MOZ_DIST_BIN}:${MOZ_DIST_BIN}/plugins:${MRE_HOME}${LD_LIBRARYN64_PATH:+":$LD_LIBRARYN64_PATH"}
> fi
> if [ -n "$LD_LIBRARY_PATH_64" ]; then
>
> LD_LIBRARY_PATH_64=${MOZ_DIST_BIN}:${MOZ_DIST_BIN}/plugins:${MRE_HOME}${LD_LIBRARY_PATH_64:+":$LD_LIBRARY_PATH_64"}
> fi
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.
> > 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?
Yes, I uploaded a new gbp build with a signed dsc and changes file.
> 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.
That's o.k. I'm in the opposite not familar with the
xul-ext-gnome-keyring package. ;)
> >> 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.
I tested yesterday the last ID build against the simple installed
xul-ext-gnome-keyring package. I couldn't see the error message like the
above within the JS error console or directly inside a terminal while
starting Icedove from the console. It seems like this issue is fixed
with the rpath linker flag.
Would be great if you could check this behavior too.
Regard
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
