Does not run on non-RedHat Linux distributions

VERIFIED FIXED in M16

Status

SeaMonkey
Installer
P3
normal
VERIFIED FIXED
18 years ago
13 years ago

People

(Reporter: Charles F Peters II, Assigned: use leaf@mozilla.org)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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

Updated

18 years ago
Summary: Does not install on stable release of Debian → Does not install on stable release of Debian
Version: other

Updated

18 years ago
Assignee: ssu → cyeh

Comment 1

18 years ago
unix install bug.
chris yeh??

Comment 2

18 years ago
briano...

do you have a good debian contact that you could forward this to?
Assignee: cyeh → briano

Comment 3

18 years ago
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.
Status: NEW → ASSIGNED

Comment 4

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

Comment 5

18 years ago
mass reassign of briano's bugs to me since he's no longer at Netscape.
Assignee: briano → granrose
Status: ASSIGNED → NEW

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M16

Comment 6

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

Comment 7

18 years ago
 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.
Assignee: granrose → leaf
Status: ASSIGNED → NEW

Comment 8

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

Comment 9

18 years ago
Add libpng.so.2 & libjpeg.so.62 to the list of exports.
Summary: Does not install on stable release of Debian → Does not run on non-RedHat Linux distributions

Updated

18 years ago
Depends on: 26315

Comment 10

18 years ago
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

18 years ago
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 staff@mozilla.org 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)
Status: NEW → ASSIGNED

Comment 12

18 years ago
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

18 years ago
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

18 years ago
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?  
topp@orn.net

Comment 15

18 years ago
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

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

Comment 17

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

Comment 18

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

Comment 19

18 years ago
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

18 years ago
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

18 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 22

17 years ago
verify,
reporter,
reopen if problem still exists
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.