Cannot replace "external" libraries packaged with mozilla

VERIFIED FIXED in mozilla0.9


Build Config
18 years ago
13 years ago


(Reporter: Robert Low, Assigned: cls)



Firefox Tracking Flags

(Not tracked)




(1 attachment)



18 years ago
When JPEG files are requested they simply display the
URL name in the layout window rather than the image.
An error message is displayed to stdout: eg.

Error loading URL resource:///res/samples/raptor.jpg: 804b0002


Error loading URL 
irix6.5/dist/bin/res/samples/raptor.jpg: 80004004

Similar errors for other JPEG images.

Using M18 (and previous) source built on SGI Irix 6.5.8m using
MIPSpro compilers.  It's using mozilla's JPEG (even if configure'd
--with-jpeg) because system native jpeg library is a lower version.

GIF and PNG display OK.

I've tracked it inside using dbx as far to discover that it knows
it's trying to do "image/jpeg" stuff.

Comment 1

18 years ago
It seems to be something strange with the component
registration stuff.  If I touch component/
and then restart mozilla then only it reregisters 
*** Registering nsJPGModule components (all right -- a generic module!)

For that session jpegs work, but if I quit and restart
again they do not.
If I remove component.reg, or touch all component libs,
to make them all reregister then it does not work. is possibly part of the problem ???

Comment 2

18 years ago
It appears to be a runtime link/loader problem.
Under general operation (not having nsjpeg reregister)
runtime linking of other DSOs gets stuff (gtk) from
/usr/freeware/lib32 and this is added to RLD's runtime
link search path (RPATH).  This results in nsjpeg's
later search for resolving with
found in /usr/freeware/lib32 which doesn't seem to work.

By touching nsjpeg and thus making it reregister at
startup makes it execute different code which results
in it resolving earlier than normal, and
finding it in mozilla's distribution directories,
before /usr/freeware/lib32 has been added to RLD's

An interim solution is to build so that
it statically links mozilla's libjpeg.a as follows:

    % cd .../mozilla/modules/libimg/jpgcom
    % gmake JPEG_LIBS=../../../dist/lib/libjpeg.a

We can do stuff in "configure" to make this permanent,
but it doesn't help the general problem of RLD resolving
with same name libraries which should be resolved within
mozilla. is another possible problem, but really
anything could end up in freeware with the same name as an
existing mozilla DSO.  Maybe we should be making symbolic
links to freeware so that it never has to be in RLD path.
Component: ImageLib → Build Config

Comment 3

18 years ago
We really need to come up with a fix for this problem across the board.  The
OS/2 guys are seeing a similar problem (bug xxxx).  If we are not going to
support dropping in replacement libraries for the completely external libraries
in the build system (png, jpeg, z), then we should rename those libraries to be
moz-specific.  If we have no moz specific bits in those directories, then we
need to figure out why an API/ABI compatible drop-in replacement isn't working.
Ever confirmed: true
OS: IRIX → All
Hardware: SGI → All
Summary: JPEGs don't display on SGI Irix (GIFs and PNGs are OK) → Cannot replace "external" libraries packaged with mozilla


18 years ago

Comment 4

18 years ago
I have been unable to see JPEG files for a long time.  Whenever I try to access a JPEG file, all I see is its URL.

Today I spent a lot of time trying to fix the problem and I was sent here by someone on  I'm on Debian GNU/Linux and I'm using a nightly build from Dec 2nd.  I have experienced this problem for a long time (since M13, I think).

The dependencies for component/ are okay (I'm using LD_LIBRARY_PATH just like does):

% LD_LIBRARY_PATH=. ldd components/ => ./ (0x40004000) => ./ (0x40016000) => ./ (0x40019000) => ./ (0x4001d000) => /lib/ (0x4004f000) => ./ (0x40065000) => /lib/ (0x40117000) => /lib/ (0x4012c000) => /lib/ (0x4012f000) => /lib/ (0x40141000) => /usr/lib/ (0x40144000) => /lib/ (0x40186000) => /lib/ (0x401a3000)
        /lib/ => /lib/ (0x80000000)

The dependencies for are okay:

% ldd => /lib/ (0x4001a000) => /lib/ (0x40030000) => /lib/ (0x40033000) => /lib/ (0x40044000) => /usr/lib/ (0x40047000) => /lib/ (0x40089000) => /lib/ (0x400a6000)
        /lib/ => /lib/ (0x80000000)

Running the beast without components.reg prints no problem registering the component.

I noticed I have and  In theory, these should cause no problems.  I tried removing them and then Mozilla would segfault.  I would get a lot of "Gtk-WARNING **: shared object not open" (not only when I run Mozilla, but when I run anything that depends on GTK; only Mozilla crashes, other applications seem unaffected... umm).  So now my guess is when (which, by the way, is not the standard distributed with Debian but my own build) gets loaded, it loads either my or my and this one conflicts (umm) with the distributed with Mozilla.

I guess my only option is rebuilding GTK in a way such that it won't load any of my files (don't have enough disk space to build Mozilla).  Hmm.

By the way, touching components/ is doing nothing for me.


Cc'ing jband for any light he can shed.


Comment 6

18 years ago
I don't have any inisght. It sounds like a platform specific library loading 
ordering issue.

Comment 7

18 years ago
On Irix the freeware and mozilla source have jpeglib.h having version as
"JPEG_LIB_VERSION  62    /* Version 6b */", but the mozilla source has
quite a few modifications from the freeware source.  When mozilla used
the freeware version it didn't work as per yours (just displayed the URL).

Maybe the Mozilla JPEG team can shed some light on the incompatibility
and changes in the mozilla jpeg code.

Comment 8

18 years ago
Adding Tom Lane to the CC list, in the hopes he can shed some light on the
differences between mozilla's jpeg and the standard jpeg-6b.

Comment 9

18 years ago
It's hard to tell if there's a library loading problem here or not.  It could
just be an ABI-level difference between the libjpeg installed on the platform
and the one built within Mozilla.  There are lots of ways that can happen even
without considering Moz-specific sourcecode changes.  (If you'd told me ten
years ago that shared libraries would be all the rage today, I'd not have
exported that big parameter struct from libjpeg ... but hindsight is always
20/20.)  Even if we brought the Moz copy of libjpeg 100% into alignment with
the standard source release of libjpeg, we could still expect to get burnt
from time to time by binary-incompatibility issues.

However, the typical result of either binary or source-level library
incompatibility would be a core dump, in my experience.  I don't have the
foggiest idea why Mozilla is simply refusing to display the image; can someone
burrow in and find out where and why libjpeg is being bypassed?

Comment 10

17 years ago
I'm looking to get a workaround/fix put into the configure script of the form:


...(as per the OS/2 change) to get JPEGS working for SGI Irix.

Would that be acceptable to people, and should I be raising an
new SGI Irix specific JPEG bug to get it tracked/checked-in via?

Comment 11

17 years ago
Screw it.  For lack on any progress whatsoever in the past 2+ years this issue
has been raised, the libraries will be renamed.
Assignee: pnunn → cls

Comment 12

17 years ago
Setting milestones to Future.


17 years ago
Target Milestone: --- → mozilla0.9

Comment 13

17 years ago
Created attachment 26615 [details] [diff] [review]
Add 'moz' prefix to jpeg, png, mng & z libs

Comment 14

17 years ago

Comment 15

17 years ago
Patch has been checked in.  Marking fixed.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 16

17 years ago
Verified checked into
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.