Closed Bug 15970 Opened 26 years ago Closed 25 years ago

Does not run on non-RedHat Linux distributions

Categories

(SeaMonkey :: Installer, defect, P3)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: cp, Assigned: leaf)

References

Details

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
Summary: Does not install on stable release of Debian → Does not install on stable release of Debian
Version: other
Assignee: ssu → cyeh
unix install bug. chris yeh??
briano... do you have a good debian contact that you could forward this to?
Assignee: cyeh → briano
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
this and bug 15976 appear to be related. this bug can probably be resolved as a duplicate, or vice versa.
mass reassign of briano's bugs to me since he's no longer at Netscape.
Assignee: briano → granrose
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: M16
*** Bug 15976 has been marked as a duplicate of this bug. ***
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
*** Bug 27697 has been marked as a duplicate of this bug. ***
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
Depends on: 26315
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.
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
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.
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.)
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
can someone from here take a look at bug 34566 and see if it is a duplicate. Thanks.
Hey again. Can someone from here take a look at bug 34330 and see if it is a duplicate. Thanks.
*** Bug 36697 has been marked as a duplicate of this bug. ***
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.
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.
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
Closed: 25 years ago
Resolution: --- → FIXED
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.