Does not run on non-RedHat Linux distributions



18 years ago
13 years ago


(Reporter: Charles F Peters II, Assigned: use


Firefox Tracking Flags

(Not tracked)




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

$ ./
./apprunner: error in loading shared libraries cannot open shared object file: No such file or

$ grep libstdc Contents-i386 |grep
usr/lib/                            base/libstdc++2.9



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


18 years ago
Assignee: ssu → cyeh

Comment 1

18 years ago
unix install bug.
chris yeh??

Comment 2

18 years ago

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.

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


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

Comment 8

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

Comment 9

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


18 years ago
Depends on: 26315

Comment 10

18 years ago
All we need to be able to run on SuSE is

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, then point the
release notes there?

If I made such a tarball and checked it in to the 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 about hosting (l)gpl'd libraries and source on the 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

18 years ago
Using SuSE 6.3. Tried to find 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,, 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 " 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?

Comment 15

18 years ago

Comment 16

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

Comment 17

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

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

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

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 -> /usr/lib/*
After having done that however, Mozilla now crashes with the words:

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

Indeed objdump shows no __bzero in 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.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 22

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