15970 - Does not run on non-RedHat Linux distributions

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P3)

Description

[Charles F Peters II]

It appears the stable release of Debian is lacking the newer library.

$ ./mozilla-apprunner.sh
MOZILLA_FIVE_HOME=/tmp/package
  LD_LIBRARY_PATH=/tmp/package
      MOZ_PROGRAM=./apprunner
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
./apprunner: error in loading shared libraries
libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or
directory

$ grep libstdc Contents-i386 |grep 1.so.2
usr/lib/libstdc++-libc6.0-1.so.2                            base/libstdc++2.9

Thanks,
Chuck

Comment 1

[Cathleen]

unix install bug.
chris yeh??

Comment 2

[Chris Yeh]

briano...

do you have a good debian contact that you could forward this to?

Comment 3

[Brian Ostrom]

Nope.  This is why I always wanted us to avoid tying ourselves to any
specific commercial Linux distribution.  Yet another example of our
consistent lack of portability....

I believe we have a similar (same?) problem with SuSe.

Comment 4

[Jon Granrose]

this and bug 15976 appear to be related.  this bug can probably be resolved as a 
duplicate, or vice versa.

Comment 5

[Jon Granrose]

mass reassign of briano's bugs to me since he's no longer at Netscape.

Comment 6

[Jon Granrose]

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

Comment 7

[cls]

 We are not going to be able to avoid this problem of incompatible libstdc++
versions as the API has changed relatively frequently over the past 5 yrs. 
IIRC, distributions that use gcc 2.7.x typically have libstdc++ 2.7.x
installed.  Once egcs was split from gcc (temporarily), libstdc++ has been
bundled with gcc making the correlation even tighter.  So egcs 1.0.x has
libstdc++ 2.8; egcs 1.1.2 has libstdc++ 2.9; and gcc 2.95.x has libstdc++ 2.10. 
It's no surprise that the various distributions of RedHat, Debian & SuSE do not
come with the same compiler & lib versions.
We need to clearly point out the library dependencies for the binaries we
release and either provide a link to the libraries or provide the libraries
ourselves (separate from Mozilla, of course).
Reassigning to leaf for a documentation & ftp site update.

Comment 8

[cls]

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

Comment 9

[cls]

Add libpng.so.2 & libjpeg.so.62 to the list of exports.

Comment 10

[Akkana Peck]

All we need to be able to run on SuSE is libjpeg.so.62.

This seems like it would be so simple to do -- even if this isn't PDT+ for
inclusion with the Netscape beta (which will cut our audience down very
substantially), couldn't we make a separate tarball containing these three
libraries (and perhaps also libgtk?) and put it on mozilla.org, then point the
release notes there?

If I made such a tarball and checked it in to the mozilla.org doc tree, would
anyone shoot me for copyright violation or wasted disk space or whatever?  I'd
really like to see everyone be able to run our beta.

Comment 11

[Daniel (Leaf) Nunes]

I won't shoot you, akk, but i will scold you for checking in binaries unnecessarily.

The problem with publishing gpl'd libraries is that we are required by law to
publish the source of those builds someplace publicly available for some
long-ish period of time. I might be going off bad hearsay, and i'd be happy to
hear that i am wrong.

Even if i'm not wrong, it might be worth having to host these extra sources and
libraries for the sake of running out of the box on more platforms. I'm not sure
where netscape would publish this source, though, since the pdms/ftp site
infrastructure is not really set up to host archived bits for long periods of time.

I'll ask [e-mail] about hosting (l)gpl'd libraries and source on the
mozilla.org ftp site.

Please don't check any tarballs into the doc tree out of frustration.

(come to think of it, i *might* shoot you with nerf darts for something like that)

Comment 12

[Dave North]

Using SuSE 6.3. Tried to find libjpeg.so.62(x) without joy; probably my own 
fumbleness with rpmfind. Seemed the easiest solution was to download and build 
Mozilla, which is no problem with supplied SuSE libs. Looks fine, works fine. 
Dependency on libjpeg (above) is unnecessary.

Comment 13

[cls]

I'm don't exactly see why this is such a big problem.  We should have the
official builds configured --without-jpeg --without-zlib --without-png.  This
would alleviate the problem for a big chunk of our users.  For people on RH6.x
systems, they should be able to just remove the mozilla copies of these
libraries if they still want to use the system versions.

libstdc++ is more of an issue, IMO.  But this can be avoided by providing links
to egcs.cygnus.com,rpmfind.net, metalab.unc.edu/pub/Linux or some other site
that can provide source and/or binaries to fullfil the dependency.

I think checking in these unrelated dependency libraries into the tree would be
a huge mistake.  Unless we are actually planning on doing development on them,
there's no gain to be had.  Expecting any binary to run "out of the box" on any
component based system is unrealistic, IMO.  In all cases, you are required to
have the correct components (rpms in this case) before the binary can run.  And
there are plenty of sites (and their mirrors) that provide space for these
components already.

And looking toward the future, when distributions start standardizing on a
future major version of gtk or libstdc++, are we going to check those copies
into our tree as well?

(Looking at rpmfind there are no libjpeg-6b rpms for SuSE 6.3 although there are
for other distributions.)

Comment 14

[wtopp]

you can add caldera 2.3 to the list where mozilla won't run.  i downloaded
the nightly on march 25 and get "libjpeg.so.62 cannot open shared object file"

can anyone point me to the library i need so i can at least get the basic 
browser running on caldera and find out that everything else works?  
[e-mail]

Comment 15

[cls]

ftp://ftp.freesoftware.com/pub/linux/redhat/old-releases/redhat-6.0/i386/RedHat/RPMS/libjpeg-6b-9.i386.rpm 
ftp://ftp.freesoftware.com/pub/linux/redhat/old-releases/redhat-6.0/i386/RedHat/RPMS/libpng-1.0.3-2.i386.rpm

Comment 16

[Asa Dotzler [:asa]]

can someone from here take a look at bug 34566 and see if it is a duplicate.  
Thanks.

Comment 17

[Asa Dotzler [:asa]]

Hey again. Can someone from here take a look at bug 34330 and see if it is a 
duplicate.  
Thanks.  

Comment 18

[Asa Dotzler [:asa]]

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

Comment 19

[Jeremy M. Dolan]

Just a note, I have *no* problem with running latest mozilla's on Slackware 7.0.

The general way to do Linux binary builds is to make it work with the most
recent librarys. If some people have to upgrade, they have to upgrade. But it
beats forcing some to DOWNgrade.

Perhaps a pre-install check for library versions, with a dialog explaining that
the user has too-old/new libraries, weither building mozilla from source would
solve this problem, and URLs/small explaination of how to install the newer
libraries.

Things like libjpeg and such aren't terribly hard for a non-technical user to
install.

Comment 20

[Lourens Veen]

Hi, I'm new here and I experienced the same problem. It's easily solved (on SuSE
6.1 at least) by symlinking libstdc++-libc6.1-1.so.2 -> /usr/lib/libstdc++.so.2*
After having done that however, Mozilla now crashes with the words:

mozilla-bin: error in loading shared libraries
/home/zeus/download/mozilla/package/libnspr4.so: undefined symbol: __bzero

Indeed objdump shows no __bzero in libnspr4.so. I haven't downloaded any source
yet, that usually solves such problems (my reason for not using rpm's, they're
usually built on RedHat and don't work on SuSE), but this error message strikes
me as odd.

Comment 21

[Daniel (Leaf) Nunes]

So, the original problem with this bug should be fixed... we build jpeg and png
and zlib out of the mozilla tree, and ship them. marking fixed.

Comment 22

[Grace Bush]

verify,
reporter,
reopen if problem still exists