27617 - Precompiled build doensn't show jpegs

Status: VERIFIED WONTFIX

(Core :: Graphics: ImageLib, defect, P3)

Description

[Florian Schmitt]

If I build Mozilla for my own everything works fine, but the precompiled builds

don't show any jpegs for me. I'm using a SuSE Linux 6.2 with Xfree 3.97. I tried

to upgrade to libjpeg.so.62 by copying the libjpeg produced by the self-compiled

mozilla to /usr/lib. But it still doesn't work (yes, I ran ldconfig).

Comment 1

[pnunn]

Thanks for the heads up. I'll see what the build folk
are doing in the precompiled builds. 
-P

Comment 2

[pnunn]

I just checked a precompiled build from the QA folks
and jpgs displayed ok.
I'll keep this open, but I'll have to push it to m15.

Would you mind cding the components directory under the
precompiled install and running:

ldd -r libnsjpg.so

This is the jpgdecoder wrapper component and the output
will tell us where it is expects the libjpeg.so  to be.

thnx,
p.

Comment 3

[Florian Schmitt]

I get the following output:



libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40012000)

        libplds3.so => not found

        libplc3.so => not found

        libnspr3.so => not found

        libpthread.so.0 => /lib/libpthread.so.0 (0x4002a000)

        libxpcom.so => not found

        libnsl.so.1 => /lib/libnsl.so.1 (0x4003c000)

        libutil.so.1 => /lib/libutil.so.1 (0x40052000)

        libresolv.so.2 => /lib/libresolv.so.2 (0x40055000)

        libdl.so.2 => /lib/libdl.so.2 (0x40065000)

        libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 (0x4006800

0)

        libm.so.6 => /lib/libm.so.6 (0x400af000)

        libc.so.6 => /lib/libc.so.6 (0x400cc000)

        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

undefined symbol: PR_Free       (./libnsjpg.so)

undefined symbol: PR_Malloc     (./libnsjpg.so)

undefined symbol: PR_Calloc     (./libnsjpg.so)

undefined symbol: NS_NewGenericFactory__FPP17nsIGenericFactoryPFP11nsISupportsRC

4nsIDPPv_UiPFv_Ui       (./libnsjpg.so)

undefined symbol: begin_assignment__13nsCOMPtr_base     (./libnsjpg.so)

undefined symbol: PR_Realloc    (./libnsjpg.so)

undefined symbol: _._13nsCOMPtr_base    (./libnsjpg.so)

Comment 4

[Florian Schmitt]

OK, it works now for me. The source of libjpeg in mozilla/jpeg didn't work as

expected in /usr/lib as libjpeg.so.62 (don't ask me why). I got the official

source of libjpeg from ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.gz, and

now everything works fine. It would be a good thing for beta to put some hints

about this on the download page. Perhaps you could include a binary build of

libjpeg?

Comment 5

[pnunn]

I'll forward this to the installer folk to see what's up.

-P

Comment 6

[Doron Rosenberg (IBM)]

*** Bug 27968 has been marked as a duplicate of this bug. ***

Comment 7

[Sverre H. Huseby]

I'm the author of the 27968 duplicate bug.  Installing jpegsrc.v6b.tar.gz
did the trick.  It seems the libjpeg.so.6.0.1 that comes with SuSE is
equivalent to libjpeg.so.61, which, as has been demonstrated, is not
compatible with the .62 that Mozilla is compiled against.  Both versions may
live in /usr/lib at once, and all programs are happy.  Thanks for the tip,
[e-mail]!

Comment 8

[Sean Su]

linux issue.  reassigning to granrose.  He might be able to help out on this.

Comment 9

[Jon Granrose]

This isn't a build issue, at least not a Netscape one as we don't build on SuSe.    
This should be relnoted.  cc'ing vera.

Relnote:

If you are running mozilla on SuSe Linux 6.2, you need to install 
libjpeg.so.62 available from ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.gz.

Comment 10

[Eli Goldberg]

Rubber-stamping as verified/WONTFIX.

Comment 11

[Akkana Peck]

Actually, it is a build issue -- we could easily include the few nonstandard
libraries we depend on in our distribution.  See bug 15970, which covers this
issue.

Comment 12

[Daniel (Leaf) Nunes]

Really depends on what you think of as ``easily.'' If we ship gpl'd libraries,
for instance, we have to publish the source for them (the *exact* source we
built with), and keep that source accessible for some large-ish amount of time.

Easy to put into the builds, harder to adjust our ftp site (i'm thinking of
netscape more than mozilla.org, but it applies in either case) for.

Maybe the right thing is to publish everything we use and include all of it in
our packages, just pointing out that it's a bit more server space to implement this.