Mozilla might not start because can not find



Build Config
17 years ago
7 years ago


(Reporter: Conor Lennon, Assigned: Asko Tontti)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: r/sr needed)


(4 attachments)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; rv:0.9+)
BuildID:    N/A

I just downloaded mozilla for linux from
If I try to run mozilla in RedHat 6.2 I get the following:

$ ./mozilla
./ ./mozilla-bin
./mozilla-bin: error in loading shared libraries:
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
2. unpack mozilla
3. run mozilla

Actual Results:  $ ./mozilla
./ ./mozilla-bin
./mozilla-bin: error in loading shared libraries:
cannot open shared object file: No such file or directory

Expected Results:  mozilla starts

Comment 1

17 years ago
I had a same problem, and resolved.

ln -s /usr/lib/ /usr/lib/

Comment 2

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

Comment 3

17 years ago
seeing this on commercial build 2001-05-04-05-trunk also
Severity: normal → blocker
Keywords: smoketest

Comment 4

17 years ago
Assignee: asa → cls
Component: Browser-General → Build Config
Ever confirmed: true
QA Contact: doronr → granrose

Comment 5

17 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

17 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

Comment 7

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

Comment 8

17 years ago
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 and
doing a search on .  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.

Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 9

17 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.
verified...updated libstdc++ rpms and smoketest machine is back on 
track...2001-05-04-08-trunk loaded fine

Comment 11

17 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

17 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

17 years ago
We should release note this at the very least

Comment 14

17 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

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

Comment 16

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

Comment 17

17 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

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

Comment 19

17 years ago
For Mandrake 8.0, did the following to resolve:

ln -s /usr/lib/  /usr/lib/libstdc++

Comment 20

17 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.
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"?

For the record, what worked for me (thanks to bbaetz) on Red Hat 7.1 was:

$ su root
$ cd /usr/lib
$ ln -s 
$ /sbin/ldconfig

This gives me confidence because the two names look pretty similar to me ;-) 


Comment 23

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

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

17 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

17 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

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

Comment 28

17 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

My /usr/lib looks like

/usr/lib/   /usr/lib/
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.a   /usr/lib/
/usr/lib/  /usr/lib/
/usr/lib/         /usr/lib/
/usr/lib/libstdc++-libc6.2-2.a.3          /usr/lib/
/usr/lib/         /usr/lib/

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


Comment 30

17 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

17 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

Comment 32

17 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

17 years ago
I only want to say Thank You to cls :)

I use RH6.2 and just installed the libstdc++ Ben Bucksch pointed to:
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

17 years ago
Created attachment 33373 [details] [diff] [review]
patch for printing more descriptive error message
You've patched the wrong file :-) Patching 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:
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 :-)

Resolution: INVALID → ---

Comment 36

17 years ago
> You've patched the wrong file :-) Patching 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.

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

17 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

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

oh, yes, I misread the patch.
I love how this incorrect meme about Red Hat's compiler in 7.0 got propagated.

s/RedHat/Red Hat/g;
I would suggest:

+                       echo "
+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?


Comment 41

17 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

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


17 years ago
Severity: blocker → normal
> 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 


Comment 44

17 years ago
Created attachment 33413 [details] [diff] [review]
updated patch

Comment 45

17 years ago
Created attachment 33414 [details] [diff] [review]
update patch (#3)

Comment 46

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

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

Comment 48

17 years ago
Created attachment 33641 [details] [diff] [review]
updated patch (#4)

Comment 49

17 years ago
r/sr needed.

Comment 50

17 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

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

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

17 years ago
Looks like we're stuck with egcs for the time being; the compiler has been
Last Resolved: 17 years ago17 years ago
Resolution: --- → INVALID

Comment 54

17 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

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

Comment 56

17 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
- 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.
Resolution: INVALID → ---
Summary: Mozilla won't start because can not find → Mozilla might not start because can not find

Comment 57

17 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: cls → atontti
Keywords: smoketest → review
Priority: P1 → --


17 years ago


17 years ago
QA Contact: granrose → ben.bucksch

Comment 58

17 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

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


17 years ago
Keywords: patch
Whiteboard: r/sr needed
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 60

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


17 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3


17 years ago
Target Milestone: mozilla0.9.3 → ---

Comment 61

17 years ago
due bug 79681.
Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX

Comment 62

17 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.)
Resolution: WONTFIX → ---

Comment 63

17 years ago
dup of bug 69198?

Comment 64

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

Comment 65

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

Comment 66

15 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


(it contains only 3 files, just enough to make everything work I suppose)

Comment 67

15 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

15 years ago
Mozilla has linked libstdc++ statically since forever and this issue is no
longer relevant.
Last Resolved: 17 years ago15 years ago
Resolution: --- → WORKSFORME

Comment 69

15 years ago
Not true. The builds on 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
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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.