57247 - Cannot replace "external" libraries packaged with mozilla

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Robert Low]

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

or

Error loading URL 
file:///disk1/sise/mozilla/devel/workpits/m17latest/workarea/obj-mips-sgi-
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 7.3.1.1m 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

[Robert Low]

It seems to be something strange with the component
registration stuff.  If I touch component/libnsjpg.so
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.

libgkplugin.so is possibly part of the problem ???

Comment 2

[Robert Low]

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 libjpeg.so resolving with libjpeg.so
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 libjpeg.so earlier than normal, and
finding it in mozilla's distribution directories,
before /usr/freeware/lib32 has been added to RLD's
path.

An interim solution is to build libnsjpeg.so 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.   libz.so 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.

Comment 3

[cls]

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.

Comment 4

[bachue]

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 irc.mozilla.org.  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/libnsjpg.so are okay (I'm using LD_LIBRARY_PATH just like run-mozilla.sh does):

% LD_LIBRARY_PATH=. ldd components/libnsjpg.so
        libjpeg.so => ./libjpeg.so (0x40004000)
        libplds4.so => ./libplds4.so (0x40016000)
        libplc4.so => ./libplc4.so (0x40019000)
        libnspr4.so => ./libnspr4.so (0x4001d000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x4004f000)
        libxpcom.so => ./libxpcom.so (0x40065000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40117000)
        libutil.so.1 => /lib/libutil.so.1 (0x4012c000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x4012f000)
        libdl.so.2 => /lib/libdl.so.2 (0x40141000)
        libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 (0x40144000)
        libm.so.6 => /lib/libm.so.6 (0x40186000)
        libc.so.6 => /lib/libc.so.6 (0x401a3000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

The dependencies for libjpeg.so are okay:

% ldd libjpeg.so
        libnsl.so.1 => /lib/libnsl.so.1 (0x4001a000)
        libutil.so.1 => /lib/libutil.so.1 (0x40030000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40033000)
        libdl.so.2 => /lib/libdl.so.2 (0x40044000)
        libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 (0x40047000)
        libm.so.6 => /lib/libm.so.6 (0x40089000)
        libc.so.6 => /lib/libc.so.6 (0x400a6000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

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

I noticed I have libjpeg.so.62 and libjpeg.so.6b.  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 libgtk-1.2.so.0 (which, by the way, is not the standard libgtk-1.2.so.0 distributed with Debian but my own build) gets loaded, it loads either my libjpeg.so.62 or my libjpeg.so.6b and this one conflicts (umm) with the libjpeg.so distributed with Mozilla.

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

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

Thanks.

Alejo.

Comment 5

[Brendan Eich [:brendan]]

Cc'ing jband for any light he can shed.

/be

Comment 6

[John Bandhauer]

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

Comment 7

[Robert Low]

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

[tor]

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

[Tom Lane]

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

[Robert Low]

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

    MOZ_JPEG_LIBS='$(DIST)/lib/libjpeg.$(LIB_SUFFIX)'

...(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

[cls]

Screw it.  For lack on any progress whatsoever in the past 2+ years this issue
has been raised, the libraries will be renamed.

Comment 12

[cls]

Setting milestones to Future.

Comment 13

[cls]

Attachment: Add 'moz' prefix to jpeg, png, mng & z libs

Comment 14

[tor]

sr=tor

Comment 15

[cls]

Patch has been checked in.  Marking fixed.

Comment 16

[Terri Preston]

Verified checked into lxr.mozilla.org