Closed
Bug 78874
Opened 23 years ago
Closed 21 years ago
Mozilla might not start because can not find libstdc++-libc6.1-2.so.3
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: conorlennon, Assigned: atontti)
References
Details
(Whiteboard: r/sr needed)
Attachments
(4 files)
1.18 KB,
patch
|
Details | Diff | Splinter Review | |
1.35 KB,
patch
|
Details | Diff | Splinter Review | |
1.36 KB,
patch
|
Details | Diff | Splinter Review | |
1.36 KB,
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; rv:0.9+) Gecko/20010503 BuildID: N/A I just downloaded mozilla for linux from mozilla.org. If I try to run mozilla in RedHat 6.2 I get the following: $ ./mozilla ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=/opt/mozilla LD_LIBRARY_PATH=/opt/mozilla:/opt/mozilla/plugins LIBRARY_PATH=/opt/mozilla:/opt/mozilla/components SHLIB_PATH=/opt/mozilla LIBPATH=/opt/mozilla ADDON_PATH=/opt/mozilla MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= ./mozilla-bin: error in loading shared libraries: libstdc++-libc6.1-2.so.3: cannot open shared object file: No such file or directory $ The last version I have that works is Build 2001050306. Reproducible: Always Steps to Reproduce: 1. download mozilla for linux from mozilla.org 2. unpack mozilla 3. run mozilla Actual Results: $ ./mozilla ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=/opt/mozilla LD_LIBRARY_PATH=/opt/mozilla:/opt/mozilla/plugins LIBRARY_PATH=/opt/mozilla:/opt/mozilla/components SHLIB_PATH=/opt/mozilla LIBPATH=/opt/mozilla ADDON_PATH=/opt/mozilla MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= ./mozilla-bin: error in loading shared libraries: libstdc++-libc6.1-2.so.3: cannot open shared object file: No such file or directory $ Expected Results: mozilla starts
Comment 1•23 years ago
|
||
I had a same problem, and resolved. Try ln -s /usr/lib/libstdc++2-libc6.1-1-2.9.0.so /usr/lib/libstdc++-libc6.1-2.so.3
Comment 3•23 years ago
|
||
seeing this on commercial build 2001-05-04-05-trunk also
Severity: normal → blocker
Keywords: smoketest
Help.
Assignee: asa → cls
Status: UNCONFIRMED → NEW
Component: Browser-General → Build Config
Ever confirmed: true
QA Contact: doronr → granrose
Comment 5•23 years ago
|
||
I believe cls updated some of the rpms on the build system last night to go to a new version of gcc.
Priority: -- → P1
Target Milestone: --- → mozilla0.9.1
Comment 6•23 years ago
|
||
I also see this error with RH 7.1. I assume this means that every distro will have the problem because RH 7.1 is one of the newer and it does not contain this new libstdc++ file. Chaging Summary to better fit bug.
Summary: Mozilla won't start in RedHat 6.2 → Mozilla won't start because can not find libstdc++-libc6.1-2.so.3
Comment 7•23 years ago
|
||
Adding myself to CC. This might be of interest to people concerned with this bug. As a result of this change of gcc version mozilla is recognising my RealPlayer plugin in the plugins directory. I'm assuming it will therefore work(but haven't the time to try it yet). (Note: I used KATO's change to get mozilla running at all, I'm also on RedHat 6.2).
Ok, so believe it or not, this is not a bug. Per bug 53486, we started using gcc 2.95.3 for the nightly builds. The newer version of gcc comes with a newer version of libstdc++ that is incompatible with the version shipped with egcs. You can find the updated libstdc++ rpms by going to http://www.rpmfind.net and doing a search on libstdc++-libc6.1-2.so.3 . People inside the netscape firewall can find the rpms at /u/cltbld/cls/rpms/ . People have mentioned making a symlink to the previous version of libstdc++ to get mozilla to run. While that is reported to work, it is not recommended. I believe most major non-RedHat distributions already come with gcc 2.95.x and libstdc++ 2.10. RedHat is the only major distribution that skipped this particular compiler version.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Comment 9•23 years ago
|
||
Leaving it up to twalker to mark this verified once his Linux box as been updated with the latest rpm and he has been able to run today's build.
Comment 10•23 years ago
|
||
verified...updated libstdc++ rpms and smoketest machine is back on track...2001-05-04-08-trunk loaded fine
Status: RESOLVED → VERIFIED
Comment 11•23 years ago
|
||
red hat still has some market share, so I guess you will make yourself alot of enemies when Mozilla doesn't work on that distribution. You can not expect the average Joe User to install a new lib he has to download from a server not known to him. Are you sure that this bug is invalid?
Comment 12•23 years ago
|
||
I agree with Jens-Uwe. As for me, I don't have a root access, so I can't upgrade. Is the new lib version absolutely necessary?
Comment 13•23 years ago
|
||
We should release note this at the very least
Comment 14•23 years ago
|
||
This sounds like a job for the installer. If the library is not there, install it. Do not leave your users twisting in the wind.
Comment 15•23 years ago
|
||
*** Bug 79002 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
*** Bug 79000 has been marked as a duplicate of this bug. ***
Comment 17•23 years ago
|
||
The fact that we require that specific version of libstdc++ is not a bug. The fact that I forgot to announce it to the world can be considered a huge bug. *dons blindfold and awaits the firing squad* Mozilla didn't work out of the box on several distributions before this change. In particular, it didn't work on distributions that had moved on to gcc 2.95.x/libstdc++ 2.10 and left egcs/libstdc++ 2.9 behind. No matter what we do, not *everyone* is going to be totally happy. It was becoming increasingly obvious that it was not worth missing out on potential performance increases and compiler fixes just so that we could run out-of-the-box on RedHat installs. If Joe User's system is missing a library, I expect them to contact their vendor (RH, debian, slackware, etc) to find out if their vendor provides that library and where they can get it. If they have no vendor pe se (net install, cheap bytes, etc), then I expect them to use the available resources (rpmfind, apt-get, google, etc) to find the library. If they don't have root access, I expect them to contact their admin about getting it installed (or compiling it themselves). Maybe that's expecting too much. Libstdc++ is a system library. Therefore, it is not covered by the Mozilla installer. You really don't want to start bundling system libraries with Mozilla. We have enough issues with size and bloat without artificially upping those numbers by bundling system libs.
Comment 18•23 years ago
|
||
*** Bug 79025 has been marked as a duplicate of this bug. ***
Comment 19•23 years ago
|
||
For Mandrake 8.0, did the following to resolve: ln -s /usr/lib/libstdc++-libc6.2-2.so.3 /usr/lib/libstdc++ -libc6.1-2.so.3
Comment 20•23 years ago
|
||
I am not sure why you seem so adament about screwing your potential users. If it is too much for the installer to actually install the library, maybe it could check for its existence, and if it is missing, it could display a message explaining how the user can fix the problem. If you do nothing, a lot of people will install Mozilla, and it will just be DOA. At this point it may not occur to everyone to check the release notes especially if the release notes are only available on the web and they do not have a working browser.
Comment 21•23 years ago
|
||
cls: Would it be possible to provide binaries built against both versions of libstdc++ for milestone releases? Or is support for the older libstdc++ likely to bitrot over time? Can we add a quick test to mozilla-installer to print a command-line message ("Your system does not have the necessary libraries to run Mozilla. Please contact your vendor and ask for libstdc++ 6.2.") rather than just "Can't find the library"? Gerv
Comment 22•23 years ago
|
||
For the record, what worked for me (thanks to bbaetz) on Red Hat 7.1 was: $ su root $ cd /usr/lib $ ln -s libstdc++-libc6.1-1.so.2 libstdc++-libc6.1-2.so.3 $ /sbin/ldconfig This gives me confidence because the two names look pretty similar to me ;-) Gerv
Comment 23•23 years ago
|
||
Gerv: I doubt that we'd want to distribute multiple binaries for milestone releases (think of the additional QA needed). At best, I think we'd end up recompiling gcc for the build machine to link against the static version of libstdc++ instead. This means more bloat but also removes this particular end-user headache. (<insert standard question about mozilla.org supplied builds: end-user vs QA>). But either way, that's not my decision. You'd have to ask staff/drivers about it. I'm pretty sure the "Can't find library" message comes from the system's dynamic loader so we wouldn't be able to override it with the installer. Since the installer is also linked against that library (I think), it probably doesn't run either. And you symlink at your own risk. :) Moehle: Screwing potential users? That's a bit dramatic, don't you think? I'd even say melodramatic as this general problem has existed since we first started distributing nightly builds. Someone somewhere is not running a glibc 2.1 system or doesn't have libstdc++ 2.9 installed. The only way for someone to *maybe* not get "screwed" is if we distributed binary that was statically linked against the system libraries. Can we say "bloat"? Again, if you think we should incur that extra penalty (whatever it is) then talk to staff@mozilla.org and/or drivers@mozilla.org. As far as being able to actually read the relnotes on the website, is there a reason the user cannot use a previous milestone release ?
Comment 24•23 years ago
|
||
Yes, eactly. Screwing potential users. Look, if Mozilla 1.0 is released and is advertised to the world as being the greatest thing since sliced bread, a lot of people will rush out to try it. If the installer won't even run for half of them but all they get instead is a cryptic message about the library being missing, what do you think they are all going to do? Some will figure it out and get the library installed. Some will just give up in disgust right then and there and never look at Mozilla again. Some will manage to make their machine unbootable by trying to "fix" the problem. And what about everyone writing reviews of Mozilla? I do not think Mozilla will get a very good review if they cannot even run it. Since it is true that the installer links against the library in question, it seems the best that can be done at this point is for the shell script that runs the binary installer to check for the library and display a clear message about what is wrong and how to go about fixing it if the library is missing. In fact, the shell script should use dialog or gdialog or some such to display its message because who knows if the installer has been started from a prompt or a file manager. The fact that mistakes like this have been made in the past does not legitimize them now. Basically, a developer's job is to make life easier for the user, not harder. If it is really necessary to make the user's life harder, as it seems to be in this case, then the developer has the obligation to do whatever is needed to mitigate the added pain. The current situation may be ok for the nightly builds, but it will never fly for Mozilla 1.0.
personally I don't think sliced bread is that great. It's more expensive and becomes dry faster
Comment 26•23 years ago
|
||
hasn't redhat been something like the "official" linux distro for mozilla for a while? Why not use redhat's compiler? The 7.1 compiler at least claims to be newer than 2.93 and I here it's at least better than the 7.0 default compiler.
Comment 27•23 years ago
|
||
*** Bug 79065 has been marked as a duplicate of this bug. ***
Comment 28•23 years ago
|
||
I don't know much about the way library versions work, but it looks as though I am required to go backwards in my library installations. I have Redhat 7.0 (and will upgrade to 7.1 when I have a few days to sort out the mess it will create) and my library versions are libstdc++-2.96-54 libstdc++-devel-2.96-54 My /usr/lib looks like /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so /usr/lib/libstdc++.so.2.7.2 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.a /usr/lib/libstdc++.so.2.7.2.8 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so /usr/lib/libstdc++.so.2.8 /usr/lib/libstdc++-libc6.1-1.so.2 /usr/lib/libstdc++.so.2.8.0 /usr/lib/libstdc++-libc6.2-2.a.3 /usr/lib/libstdc++.so.2.9 /usr/lib/libstdc++-libc6.2-2.so.3 /usr/lib/libstdc++.so.2.9.dummy I.e., I am on a release of libstdc++-libc6.2, not libstdc++-libc6.1. Do you want me to downgrade? How is it that I am currently running Build 2001050315 on exactly that set of libraries? From what you have written, I get the impression that you have UPgraded your own build installation. If that is the case, the previous builds were happily working with later versions of the libraries. Whay can that situation not continue?
Comment 29•23 years ago
|
||
> I'm pretty sure the "Can't find library" message comes from the
> system's dynamic loader so we wouldn't be able to override it with the
> installer.
As someone else said, we could add a test to the script mozilla-installer
(mozilla-installer-bin is the exe linked against libstdc++; the
mozilla-installer script calls it.) The two things to do are:
1) Work out what the foolproof test is for the correct library (there must be
some command-line program which does this)
2) Write a message to display.
Gerv
Comment 30•23 years ago
|
||
I would like to say that sysadmins will sometimes refuse to upgrade (because they already have too much work); this is *often* the case in France. So, is it possible to install the library in the user's home directory? What files are needed? Only the .so.3 file? Perhaps you should have web pages (or pointers to non-Mozilla pages) that explain such things and where to get the files... In my case, when I asked the sysadmins to upgrade because of an annoying bug in glibc, they told me that I have to wait (I don't know how much). But if I upgrade, this will be the next version of the stdc++ library (not the one used by Mozilla). I think it isn't nice to use a library that isn't present on some systems, in particular from main vendors. And IMHO, it would be better to announce the library change several weeks before, if possible, so that the concerned vendors can do something about this.
Comment 31•23 years ago
|
||
> Look, if Mozilla 1.0 is released and is > advertised to the world as being the greatest Mozilla should not be advertized to the world. I agree with cls. gcc 2.95.x is reported to be a much better compiler than egcs (I didn't experience first-hand). Not only optimizations, but also for C++ standards support (templates, namespaces, exceptions etc.). Also, as time goes on, lelss distros will ship with egcs compat libraries, so you could end up being compatible with RH and nothing else. The lib install note should not be in release-notes, but the install instructions. If you don't read them: your problem. As for the installer, I don't care too much (that's more Netscape's domain), but I agree that something in the installer (e.g. its start script) should check for the lib existiance. File a new bug, if you want that. > Why not use redhat's compiler? The 7.1 compiler The 7.0 compiler (dunno about 7.1) was complete crap: not compatible with *anything* else. So, if you use that, you are garanteed to piss off all users (incl. RH6.x users) but the RH7 ones. It is entirely Redhat's fault that they used their own 2.96 and not the common 2.95.x in RH7. Blame them. > Do you want me to downgrade? See bug 53486, comment From Ben Bucksch 2001-05-06 07:33. > Whay can that situation not continue? Because we can't use that age-old egcs forever. > in particular from main vendors s/main vendors/one main vendor/ > So, is it possible to install the library in the user's home directory? Yes, install it somewhere and then set LD_LIBRARY_PATH to that dir (e.g. |export LD_LIBRARY_PATH="/home/steve/libs/"|).
Comment 32•23 years ago
|
||
The installation instructions in the README should be updated immediately to reflect this complication. They should state what the preferred solution is for RedHat users. They should also include the workaround of installing the library in the user's directory and setting LD_LIBRARY_PATH as suggested for those who don't have root access. The README specifically says that you should have RedHat 6.0 or later to run Mozilla on Unix (sic). This is no longer the case. Users are being punished (albeit unintentially) for trying to install Mozilla under the prescribed platform. The vast number of end users will be installing rpm's and deb's rather than tarballs, anyway, many of them tweaked for a particular distribution. Will it continue to be possible for vendors to compile Mozilla against the older libraries?
Comment 33•23 years ago
|
||
I only want to say Thank You to cls :) I use RH6.2 and just installed the libstdc++ Ben Bucksch pointed to: http://www.beonex.de/download/communicator/0.6/req/libstdc++-2.95.2-7mdk.i586.rpm with "rpm -i libstdc++-2.95.2-7mdk.i586.rpm" This left all other files intact - nothing broken or odd floating around. And afterwards, as others commented: I can FINALLY watch RealPlayer inline. Mighty pleased with this move.
Assignee | ||
Comment 34•23 years ago
|
||
Comment 35•23 years ago
|
||
You've patched the wrong file :-) Patching run-mozilla.sh won't help because it's the installer that bombs out. You need to patch the script "mozilla-installer". I'm reasonably sure it lives here: http://lxr.mozilla.org/seamonkey/source/xpinstall/wizard/unix/src2/mozilla-insta ller given that that is the only file of that name in the source tree. Reopening this bug to cover the "print a nice error message" issue. cls: if you don't want it assigned to you, feel free to assign it to me :-) Gerv
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
Comment 36•23 years ago
|
||
> You've patched the wrong file :-) Patching run-mozilla.sh won't help because
> it's the installer that bombs out.
Not quite. *Both* crash. So, patching run-mozilla will help for those who don't
use the installer.
Patch:
Please give a more meaningful help or refer the more meaningful help. I hate
error msgs that tell me "Contact your system administrator", since *I am* the
system administrator.
It might also be nice to print the output of
ldd $prog | grep 'libstdc\+\+'
directly to the console.
Assignee | ||
Comment 37•23 years ago
|
||
Gervase: I can also do patch for the installer when I get home. Ben: The patch prints the output of ldd to to current "console", so what you mean? And I thought that the message should be short so it says: +More information can be found from installation and release notes.
Comment 38•23 years ago
|
||
> The patch prints the output of ldd to to current "console"
oh, yes, I misread the patch.
Comment 39•23 years ago
|
||
I love how this incorrect meme about Red Hat's compiler in 7.0 got propagated. s/RedHat/Red Hat/g; http://www.bero.org/gcc296.html
Comment 40•23 years ago
|
||
I would suggest: + echo " +FATAL ERROR + +Your system doesn't have required C++ run-time environment (libstdc++ +6.1-2 or greater) for running this program. Please, contact your +system administrator or vendor to upgrade your system to required level. + +More information can be found in the installation and release notes, +found at <URL>. +" We should give a URL because if they have the installer, they can't get at the installation and release notes. We also need to give the version number required, but I may have got that wrong - someone please correct me. We also have a i18n problem here... Is there anything we can do about that? Gerv
Comment 41•23 years ago
|
||
cat chrome/locale/default/runtime/missing-libstdc.error where default is a symlink to a random locale. A reminder that the installer should be considered in bug 79065 and perhaps bug 68604 [i don't think solaris mozilla builds actually need the library, only the installer does].
Comment 42•23 years ago
|
||
Gerv, you don't need to include the version number, because the actual required version is put out. d/ to required level/ Posted reply to blizzard to .builds.
Updated•23 years ago
|
Severity: blocker → normal
Comment 43•23 years ago
|
||
> cat chrome/locale/default/runtime/missing-libstdc.error
>
> where default is a symlink to a random locale.
This won't work for the installer, because it's all packed up in XPIs. We'd have
to include the error message file directly in the tar.gz. And if you do that,
you might as well have the string as a var at the top of the script.
Also, for the Mozilla executable itself, there is no such symlink as the default
symlink - it's all handled internally through chrome URL magic, which we don't
have.
Gerv
Assignee | ||
Comment 44•23 years ago
|
||
Assignee | ||
Comment 45•23 years ago
|
||
Assignee | ||
Comment 46•23 years ago
|
||
1) I think that i18n is not worth the effort. There is so many things that can go wrong with it. I could emulate this with LC* environment variables if you really want it. 2) installer still needs a patch. I submitted one to bug 79065 as timeless wanted. 3) We cannot hardcode versions into the error message because we don't know which gcc was used to build binary - so we ask from ldd. 4) Release notes need a description for this error with possible workarounds (relnote keyword?) 5) s/upgrade your system./upgrade the system./
Comment 47•23 years ago
|
||
> The 7.0 compiler (dunno about 7.1) was complete ****:
> not compatible with *anything* else. So, if you use
> that, you are garanteed to **** off all users
Your statement regarding compatibility is "complete ****." As referenced by
Christopher Blizzard, no release of gcc is compatible with *anything* else, at
least in terms of C++ libraries. It's compatible in pretty much every way. The
fact there's *no* standard platform for C++ on Linux is why most software
developed with C++ is distributed statically linked.
At this point, gcc 2.96 is the best compiler available, and is used in both Red
Hat 7 and Mandrake 8 (Debian and SuSE are the major distributors using gcc
2.95.2). As those are the two biggest distributors of Linux in the US, I
suggest that you target them to **** off the smallest number of users possible.
Whatever compiler you end up using, I would hope that you find some way to make
this work for everyone possible. If you aren't going to use the
widely-available, somewhat compatible, egcs 1.1, then it would probably be best
to staticly link the C++ library (yes, bloat), or include the .so in the package
(still bloat, but only file size, not memory). Maybe mix the two... Staticly
link the installer and have it download and install the .so if it's not present
in the system.
Assignee | ||
Comment 48•23 years ago
|
||
Assignee | ||
Comment 49•23 years ago
|
||
r/sr needed.
Comment 50•23 years ago
|
||
I for one would recommend strongly that Moz followed the /official/ compiler/library track for GCC. GCC is x-platform and it is more obvious to me to install an official release on Solaris, BSD, AIX, HP-UX and build with that than search out an oddball intermediate version. The source code to Moz is cross-compiler but that only stands as long as language & library standards are observed. Mozilla (and especially the nightlies) is an engineering platform /not/ an end-user product. This being the case, users ought to be able to tech savvy enough to update the libraries. Caveat Emptor.
Comment 51•23 years ago
|
||
For the record, it was expressly advised by the GCC Steering Committee that GCC version 2.95.x and its related libstdc should be used for productions purposes, see in http://www.gnu.org/software/gcc/gcc-2.96.html. Mozilla may not end being an end-user product, but it will surely be a "product", in the sense of a complete browsing package. One can imagine what could happen if they started using all sorts of experimental compilers and libraries.
Comment 52•23 years ago
|
||
Guys, we're not talking about using Red Hat's compiler for 7.x ( 2.96RH ) so stop worrying about it. That won't happen.
Comment 53•23 years ago
|
||
Looks like we're stuck with egcs for the time being; the compiler has been reverted.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
Comment 54•23 years ago
|
||
I would hope that the reversion to egcs 1.1 does not stand for very long, based on what others have said about the benefits of the use of gcc 2.95.3 (or better?). Having a statically linked installer with the ability to prompt for and/or download the appropriate libstdc++ seems quite reasonable and necessary, given the mess that is C++ on Linux to date.
Comment 55•23 years ago
|
||
verified. time to stop talking about this, my inbox is sick of it already.
Comment 56•23 years ago
|
||
- I opened a thread on builds to catch discussion about the saneness of gcc 2.96 or it being the compiler for a distro. Please direct comments about that topic there. - Why has the compiler choice been reverted? - Most imporantly: I would like the patch or a variant of it to go into the tree. Beonex Communicator release builds are built with gcc 2.95 and it is a useful warning msg. It is independant of the compiler choice, so it can go in regardless of the compiler choice of the Mozilla builds. Thus, I'm chainging the SUMMARY slightly and REOPEN. Reassing to Asko, who created the patch. Somebody qualified please review the patches.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: Mozilla won't start because can not find libstdc++-libc6.1-2.so.3 → Mozilla might not start because can not find libstdc++-libc6.1-2.so.3
Comment 57•23 years ago
|
||
> time to stop talking about this, my inbox is sick of it already.
Ops. I'm sorry to annoy you, but I think the patch is useful. Feel free to pass
QA to somebody else.
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Updated•23 years ago
|
QA Contact: granrose → ben.bucksch
Comment 58•23 years ago
|
||
How do we get back to the old library. I could not launch yesterday's build 2001050914. No crash, just stopped.
Comment 59•23 years ago
|
||
Yesterday's builds may have been screwed up slightly. Extermely bad timing on reverting the compiler. Try this morning's build. You shouldn't have to "get back" the old library as the new one is installed in a different location and using a different rpm name. |rpm -e libstdc++295| if you really think it's affecting your build.
Assignee | ||
Updated•23 years ago
|
Comment 60•23 years ago
|
||
*** Bug 83928 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → ---
Assignee | ||
Comment 61•23 years ago
|
||
due bug 79681.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
Comment 62•23 years ago
|
||
nope. that bug is not yet fixed. even if so, it probably won't be enabled by default. So, users are still "vulnerable" to this bug. (Mostly those of Netscape 6, since Mozilla testers should sort this out themselves and Beonex indeed uses statical linking.)
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 63•23 years ago
|
||
dup of bug 69198?
Comment 64•23 years ago
|
||
*** Bug 128576 has been marked as a duplicate of this bug. ***
Comment 65•21 years ago
|
||
*** Bug 200902 has been marked as a duplicate of this bug. ***
Comment 66•21 years ago
|
||
This library isn't installed per default on my system...., but found the right tpm and from there it is easy.It would be easier if mozilla would check on them during install, since there is more than one post about this ad far as I've noticed. Installing an rpm is ofcourse very easy, but this is easier, because you don't have to search what's wrong, flash works now....:) I've used the following rpm, you can search for on rpmfind.net: libstdc++-2.95.2-12mdk.i586.rpm (it contains only 3 files, just enough to make everything work I suppose)
Comment 67•21 years ago
|
||
If you're using Redhat Linux any version you have, install 'compat-libstdc++-x.x...rpm' to resolve this problem. These libraries are necessory to execute some applications including Mozilla but not essential, so sometimes this package did not installed according to your choice while installation.
Comment 68•21 years ago
|
||
marking WORKSFORME Mozilla has linked libstdc++ statically since forever and this issue is no longer relevant.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → WORKSFORME
Comment 69•21 years ago
|
||
Not true. The builds on mozilla.org may do so by now, which is good, but the default builds from source (version 1.4.x) don't, and I don't see a configure option to enable it. Run the following script in the Mozilla dir to see the full glory of runtime dependencies: export LD_LIBRARY_PATH="."; find . -name "*.so" -or -name "mozilla-bin"|xargs -n 1 ldd|sed -e "s/ (.*//"|grep -v "=> ./"|sort|uniq However, this particular bug is by now very obsolete, given that all Linux distros moved on to new compiler versions by now. VERIFIED.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•