78874 - Mozilla might not start because can not find libstdc++-libc6.1-2.so.3

Status: VERIFIED WORKSFORME

(SeaMonkey :: Build Config, defect)

Description

[Conor Lennon]

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

[KATO Hiroshi]

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 2

[Doron Rosenberg (IBM)]

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

Comment 3

[Tracy Walker [:tracy]]

seeing this on commercial build 2001-05-04-05-trunk also

Comment 4

[timeless]

Help.

Comment 5

[Jon Granrose]

I believe cls updated some of the rpms on the build system last night to go to a
new version of gcc.

Comment 6

[Greg Breland]

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.

Comment 7

[Robert Wall]

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).  

Comment 8

[cls]

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.

Comment 9

[J.J. Enser]

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

[Tracy Walker [:tracy]]

verified...updated libstdc++ rpms and smoketest machine is back on 
track...2001-05-04-08-trunk loaded fine

Comment 11

[Jens-Uwe]

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

[Vincent Lefevre]

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

[scalkins]

We should release note this at the very least

Comment 14

[Stephen Moehle]

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

[R.K.Aa.]

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

Comment 16

[R.K.Aa.]

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

Comment 17

[cls]

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

[R.K.Aa.]

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

Comment 19

[Roger]

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

[Stephen Moehle]

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

[Gervase Markham [:gerv]]

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

[Gervase Markham [:gerv]]

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

[cls]

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 [e-mail]
and/or [e-mail].  

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

[Stephen Moehle]

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.

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

personally I don't think sliced bread is that great. It's more expensive and 
becomes dry faster

Comment 26

[a-huntwork]

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

[R.K.Aa.]

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

Comment 28

[Peter B. West]

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

[Gervase Markham [:gerv]]

> 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

[Vincent Lefevre]

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

[Ben Bucksch (:BenB)]

> 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

[Leston Buell]

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

[R.K.Aa.]

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.

Comment 34

[Asko Tontti]

Attachment: patch for printing more descriptive error message

Comment 35

[Gervase Markham [:gerv]]

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

Comment 36

[Ben Bucksch (:BenB)]

> 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.

Comment 37

[Asko Tontti]

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

[Ben Bucksch (:BenB)]

> The patch prints the output of ldd to to current "console"

oh, yes, I misread the patch.

Comment 39

[Christopher Blizzard (:blizzard)]

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

[Gervase Markham [:gerv]]

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

[timeless]

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

[Ben Bucksch (:BenB)]

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.

Comment 43

[Gervase Markham [:gerv]]

> 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

Comment 44

[Asko Tontti]

Attachment: updated patch

Comment 45

[Asko Tontti]

Attachment: update patch (#3)

Comment 46

[Asko Tontti]

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

[Gordon Messmer]

> 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.

Comment 48

[Asko Tontti]

Attachment: updated patch (#4)

Comment 49

[Asko Tontti]

r/sr needed.

Comment 50

[neil.corlett]

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

[Fernando K. Noda]

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

[Christopher Blizzard (:blizzard)]

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

[cls]

Looks like we're stuck with egcs for the time being; the compiler has been
reverted. 

Comment 54

[Jonathan Abbey]

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

[Jon Granrose]

verified.  time to stop talking about this, my inbox is sick of it already.

Comment 56

[Ben Bucksch (:BenB)]

- 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.

Comment 57

[Ben Bucksch (:BenB)]

> 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.

Comment 58

[Paul Wyskoczka]

How do we get back to the old library.  I could not launch yesterday's build
2001050914.  No crash, just stopped.

Comment 59

[cls]

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.

Comment 60

[Cyd]

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

Comment 61

[Asko Tontti]

due bug 79681.

Comment 62

[Ben Bucksch (:BenB)]

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.)

Comment 63

[R.K.Aa.]

dup of bug 69198?

Comment 64

[R.K.Aa.]

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

Comment 65

[WD]

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

Comment 66

[Michel Brabants]

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

[JHB]

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

[Andrew Schultz]

marking WORKSFORME
Mozilla has linked libstdc++ statically since forever and this issue is no
longer relevant.

Comment 69

[Ben Bucksch (:BenB)]

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.