Red Hat Bugzilla – Bug 186801
djvu images abort firefox on x86_64 FC5 system
Last modified: 2007-11-30 17:11:28 EST
Description of problem:
Plugin aborts firefox on x86_64
Version-Release number of selected component (if applicable):
Display a Web page with embedded djvu images
Steps to Reproduce:
0. Run FC5 on an x86_64 system
1.go to http://www.teletrade.com/coins/
2.select any of the lots under Thumbnail Images
3.Watch firefox disappear without any messages
Web page displayed with djvu images
Just found out that firefox aborts with status code 139
Sorry for the huge delay in responding, but could you please try the 3.5.17
packages that should appear real shortly and confirm if the problem still happens?
I uninstalled and reinstalled the djvulibre package. I get different results
from mozilla and firefox.
[gc@orion ~]$ uname
Linux orion 2.6.17-1.2139_FC5 #1 SMP Fri Jun 23 12:40:11 EDT 2006 x86_64 x86_64
[gc@orion ~]$ rpm -q djvulibre mozilla firefox
Mozilla - Plugin shown in "about:plugins". Aborts with segfault when I display a
page with embedded image (e.g. from teletrade.com/coins)
Firefox - No plugin shown, brings up an external viewer (djview) when a page is
I've just pushed a new build of 3.5.18 for Fedora development (to be 7). Can you
easily test that? Do you want me to put some testing packages for FC6 x86_64
I've quickly tested 3.5.18 on an x86_64 FC6 machine, but unfortunately I'm
running an i386 firefox. I installed seamonkey, but the plugin doesn't show
up... weird, as /usr/lib64/mozilla/plugins is provided, and even a symlink in
/usr/lib64/seamonkey-1.0.7/plugins doesn't make it appear.
Please put the FC6 packages somewhere, I will test. I am trying to learn enough
about xen to be able to run development systems, but it is slow going.
djvulibre 3.5.18 has now been pushed to FC-5 and FC-6, so you can simply update
your system and let me know if the update fixes this issue.
I have now a similar (same?) problem with djvulibre-3.5.18; this solved
Bug 228193 for me, but now the plugin aborts immediately when viewing a
On the other hand, compiling the original src.rpm file from djvulibre.org gives
a viewer which works both in standalone and browsing mode. So the problem
has to do with the build process.
What about compiling the Fedora .src.rpm on the same system? Does that still
give you the problem?
- If yes, then it's something in the Fedora spec file, possibly the optflags
- If not, then it's something in the Fedora build system and/or build requirements
Can you test this? It will definitely help track down the problem.
I just checked, and after building the src.rpm from Fedora, it works fine both
in standalone and browsing mode.
Thanks a lot. Then to continue digging, I'd appreciate if you could :
- Attach the complete build output of a locally rebuilt Fedora package :
rpmbuild ...blablabla... 2>&1 >/tmp/djvulibre.log
- Post the output of "rpm -q --requires djvulibre" for the working package.
Created attachment 147982 [details]
Log for a complete build of djvulibre-3.5.18 on Dell D820
Created attachment 147983 [details]
Output of rpm -q --requires djvulibre
So... no differences in the requirements. So far, so good.
But the build logs shows a few differences :
- Fortran is found in your build environment (I doubt it makes any difference)
- libtool is found in your build environment (this might cause some difference)
- Lots of warnings are present during my build, but not during yours (!?)
The warnings differences are strange, since both builds are using the exact same
CFLAGS. I'll continue looking...
I've been able to reproduce the problem and after some testing, here is my
conclusion : Djvulibre isn't multilib capable...
- When I install both x86_64 and i386 packages, the plugin doesn't work
- When I install _only_ the i386 package, the plugin works
Note that I have an i386 firefox installed, although my system is x86_64, in
order to get flash working. From the requirements of your rebuilt package, I
assume you do too.
I don't see any simple solution here, apart from renaming all the binaries from
one of the archs, so that no 32bit binaries get overwritten when both archs are
installed, then modifying the plugin to call the right programs... any better ideas?
For now, the workaround would be to install _only_ the package from the arch you
require, and not _both_. Can you let me know if it works for you?
Actually my laptop is not x86_64 (Core Duo, not Core 2 Duo).
Curiously, I've just tried again the updated rpm (downloaded from the extras web
site, and also re-installed via yum), and this time everything worked fine.
So in my case there is no problem left, just a strange situation.
Maybe the overall yum update this morning picked the wrong package the first
Can you give the latest 3.5.19-2.fc8 package a try?
Don't mind the fc8 tag, it should install and run fine on Fedora 7. If it works
now, I think I won't go looking any further and close this bug... it's confused
me more than enough already ;-)
I still haven't been able to reproduce the problem with the latest package, so
I'll close as WORKSFORME. Please reopen the bug if you manage to still see it.