User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Build ID: 20110930020335 Steps to reproduce: Installed FF8 on new x86_64 system. FF won't start. Actual results: XPCOMGlueLoad error for file /home/usrlocal/bin/firefox/libxpcom.so: libxul.so: cannot open shared object file: No such file or directory Couldn't load XPCOM. Expected results: FF should have started; but it appears to search the wrong places for some files. See comments in attached strace log....

Found the nightly builds and downloaded: Created firefox$VERSION and .mozilla$VERSION directories and can invoke any version with this simple "ff <version>" script: #!/bin/bash VERSION=$1 [ -L $HOME/.mozilla ] && rm -f $HOME/.mozilla ln -s $HOME/.mozilla$VERSION $HOME/.mozilla [ -L $HOME/firefox ] && rm -f $HOME/firefox ln -s $HOME/firefox$VERSION $HOME/firefox firefox/firefox & Tried versions 8, 9, 10 and 11... the only one that works on my system is 11.0a1 (2011-11-21) All others produce the reported error.

(In reply to Pierre Fortin from comment #0) > XPCOMGlueLoad error for file /home/usrlocal/bin/firefox/libxpcom.so: Your username on that machine is "usrlocal"?

Why do you wonder why FF is looking for 32-bit libs? On the first line of the log you write it is running in 32-bit mode. Have you downloaded the proper FF binary? 32bit or 64bit? You write /usr/local/bin is a symlink to /home/usrlocal/bin . Do you have permissions there? What does $HOME resolve to in your script? I wonder what is in $HOME/firefox$VERSION, where is "/bin" in there?

re comment 2: No... over the years, I've refined how to assign partitions -- from the days of separate partitions for {/,/usr,/var,/home,...} to simply / and /home As a result, only / gets hit when doing a re-install. So /usr/local/{bin,src} are symlinks to /home/usrlocal/{bin,src} which avoids a lot of work re-loading my /usr/local stuff. /etc is another story; but that's orthogonal to this discussion... :) re comment 3: That's an strace output... didn't notice it at the time... but is that strace and/or ff8, or both running in 32-bit mode? Likely both? Got this, my first 64bit machine a few days ago, so sorry for any confusion... When I go to getfirefox.com, there is no 32 v. 64 bit choice, only whatever the site decides I need... right now, I see 8.0.1[note 1] is available... (firefox-8.0.1.tar.bz2) -- is this 32 or 64? The symlink is as described above with permissions just as they would be if at /usr/local/bin/... Been doing that for years. My wrapper script (/home/pfortin/bin/ff) adds symlinks to the version I ask it to run... i.e., $ ff 11 does: remove the old links add links to .mozilla11 and firefox11 starts the version pointed to by the symlinks nothing more than a minor slight of hand... $HOME/firefox$VERSION becomes /home/pfortin/firefox{8,9,10,11} as per $1 /bin..?? where else do you expect to find a "rooted" path? OK... assuming that's a 32 bit binary, my question inside the strace log (middle) is still valid: why does FF stop looking in the path where it is located, and start looking in system paths? Here's the setup: $ ll -d /home/pfortin/firefox* lrwxrwxrwx 1 pfortin pfortin 23 Nov 22 10:37 /home/pfortin/firefox -> /home/pfortin/firefox11/ drwxr-xr-x 11 pfortin pfortin 4096 Nov 21 07:45 /home/pfortin/firefox10/ drwxr-xr-x 10 pfortin pfortin 4096 Nov 21 06:10 /home/pfortin/firefox11/ drwxr-xr-x 10 pfortin pfortin 4096 Nov 21 06:10 /home/pfortin/firefox11.bak/ drwxr-xr-x 10 pfortin pfortin 4096 Nov 21 06:10 /home/pfortin/firefox8/ drwxr-xr-x 12 pfortin pfortin 4096 Nov 16 13:59 /home/pfortin/firefox9/ When I try to run FF8, the symlink points to /home/pfortin/firefox8/ which contains: $ find /home/pfortin/firefox8 -name libxul.so /home/pfortin/firefox8/libxul.so $ find /home/pfortin/firefox8 -name libxpcom.so /home/pfortin/firefox8/libxpcom.so yet, FF8 can't find them... I setup the symlink wrapper only after finding that FF8 would not run at /home/pfortin/firefox, /usr/local/bin/firefox, or anywhere else I tried installing it... HTH Note 1: Downloaded 8.0.1 (only choice given)... # cd /usr/local/bin # really at /home/usrlocal/bin # tar xf /home/pfortin/Downloads/firefox-8.0.1.tar.bz2 # As normal user: $ file /usr/local/bin/firefox/firefox /usr/local/bin/firefox/firefox: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped $ /usr/local/bin/firefox/firefox XPCOMGlueLoad error for file /home/usrlocal/bin/firefox/libxpcom.so: libxul.so: cannot open shared object file: No such file or directory Couldn't load XPCOM. Again, in the 8.0.1 strace output, after closer examination, it appears FF *does* know where to find libxul.so and libxpcom.so -- yet complains...

getfirefox.com only offers 32-bit builds, 64-bit is not yet officially promoted. Get a 64bit version here. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ I just wondered why in the first strace FF is looking (and finding files) in /home/usrlocal/bin/firefox/ when you now say (and the script too) you have the firefox packages extracted at /home/pfortin/firefox* (no "bin" in the path). Where FF looks for libs may depend on whether you have "." in your $PATH.

I'll try this one later today... I have to go out for a while... LOL... looks like I've confused you inadvertently... I tried extracting firefox in various places: - the home directory of the account I always use - /usr/local/bin to test in another account while I kept ff11 open in home account. Actually, if I was doing this while less sleepy, I would have extracted all those versions in /usr/local/bin and set the firefox symlink (not .mozilla) in $HOME/bin pointing to /usr/local/bin/firefox<N>..... OOOPS.... that would also require that there is no /usr/local/bin/firefox because it would be ahead of $HOME/bin in $PATH... stumbled into avoiding confusion without forethought... LOL "." in $PATH is deprecated as a safety measure; forces user to explicitly specify ./proggy if that's desired... too many potential accidents otherwise. BTW, when I searched for this problem, I did find a not insignificant number of reports for this problem... though I was surprised it wasn't reported here yet.

OK, so please clean it up, extract all those versions into one place (get real 64bit builds) and report what happens :) I also install multiple FF versions into my $HOME and run them as ./firefox$version/firefox and have never seen a problem like you describe (but I am on 32bit). So I am curious what happens in your system.

I also watch a similar report in bug 685433. Maybe you can try what the user there is doing. He gets the same message but could find out which library is missing.

re comment 8: Already stated in comment 1: > Tried versions 8, 9, 10 and 11... > the only one that works on my system is 11.0a1 (2011-11-21) ^^^^^^^^^^^^^^^^^^^^^^^ Of course, it's now more obvious that only 11 is 64bit... re comment 9: removed all firefox versions. re-extracted versions into: # ll -d fire* drwxr-xr-x 11 root root 4096 Nov 21 07:45 firefox10.0a2/ drwxr-xr-x 10 root root 4096 Nov 21 06:10 firefox11.0a1/ drwxr-xr-x 11 root root 4096 Nov 4 21:54 firefox8.0/ drwxr-xr-x 11 root root 4096 Nov 20 18:00 firefox8.0.1/ drwxr-xr-x 12 root root 4096 Nov 16 13:59 firefox9.0b2/ Using this modified wrapper: VERSION=$1 [ -L $HOME/.mozilla ] && rm -f $HOME/.mozilla [ -d $HOME/.mozilla$VERSION ] && ln -s $HOME/.mozilla$VERSION $HOME/.mozilla cd /usr/local/bin/firefox${VERSION} echo `pwd` sleep 1 LD_LIBRARY_PATH=`pwd` ./firefox pierre@hg ~ 18:46:45 $ ff 8.0 /usr/local/bin/firefox8.0 XPCOMGlueLoad error for file /home/usrlocal/bin/firefox8.0/libxpcom.so: libXrender.so.1: cannot open shared object file: No such file or directory Couldn't load XPCOM. pierre@hg ~ 18:46:57 $ ff 8.0.1 /usr/local/bin/firefox8.0.1 XPCOMGlueLoad error for file /home/usrlocal/bin/firefox8.0.1/libxpcom.so: libXrender.so.1: cannot open shared object file: No such file or directory Couldn't load XPCOM. pierre@hg ~ 18:47:09 $ ff 9.0b2 /usr/local/bin/firefox9.0b2 XPCOMGlueLoad error for file /home/usrlocal/bin/firefox9.0b2/libxpcom.so: libXrender.so.1: cannot open shared object file: No such file or directory Couldn't load XPCOM. pierre@hg ~ 18:47:29 $ ff 10.0a2 /usr/local/bin/firefox10.0a2 XPCOMGlueLoad error for file /home/usrlocal/bin/firefox10.0a2/libxpcom.so: libXrender.so.1: cannot open shared object file: No such file or directory Couldn't load XPCOM. pierre@hg ~ 18:47:53 $ ff 11.0a1 /usr/local/bin/firefox11.0a1 #### this one works (64 bit version) pierre@hg ~ 18:48:25 $ I know... I know... the others are all 32 bit... BUT... what is the average user to think when they have recently moved to Linux and are trusting mozilla to suggest the correct version...??? NOTE that the original report was libxul.so, and with: LD_LIBRARY_PATH=`pwd` ./firefox it's libXrender.so.1 that's complained about here... As the OP in bug 685433 suggested nearly 3 months ago: > We should probably have some more user-friendly message of some sort. Amen! So far, the report was about libxul; but now libXrender is it... and: > I doubt many users are going to add LD_LIBRARY_PATH=`pwd` to their command line. To that, I would add that not many users would even know to do that AFTER doing: cd <firefox_dir> or issuing [path/|./]firefox<version>/firefox So... if someone installs a 32bit OS, no problem. Actually did that when I first setup this machine until I got my hands on 64bit version; then ff8 failed for now obvious reason... Note that ff doesn't say where it's looking for libXrender.so.1 (short of strace).... the ONLY version available to me (no 32bit libs) is: ‎/usr/lib64/libXrender.so.1 My recommendation would be for mozilla to not only detect the basic OS; but point 64bit users to appropriate binaries... that would avoid a lot of grief, and bad-mouthing of ff by those who get these errors without understanding the difference... I'm a ff advocate, not just a regular user -- I don't like seeing easily avoidable targets that can harm its reputation... That said, I HATE IE... :) PS: are there ff{8,9,10} 64bit binaries? I only found 64bit at ff 11 level... Aurora & beta only seem to have 32bit versions...

There are Auroras and Betas marked 64bit (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/ , http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/9.0b3-candidates/build1/linux-x86_64/) but I can't say what they really are. You must try them. You can also vote in bug 702030 so that the main download pages of mozilla offer you 64bit versions automatically (if you visit them with a 64bit version of browser).

I have observed this "Couldn't load XPCOM" error message too, and indeed as suggested by 685433, adding firefox's install dir to LD_LIBRARY_PATH does the trick. However, I have noticed that it started occurring with ff7, when 'firefox' was changed from a shell script into an ELF binary; it looks like run-mozilla.sh used to configure LD_LIBRARY_PATH properly, and this has probably disappeared in the new implementation. Maybe it should be resurrected? As a side note, I have noticed that when I start firefox from thunderbird (by clicking on a hyperlink), ff does start.... My use case is: I have an (old) RedHat 4 machine (64 bits but it doesn't matter), no admin rights (and probably no updates to the ff package), and I download your firefox official releases to keep up to date.

I had this error running the normal 32-bit Firefox on 64-bit Debian squeeze, with ia32-libs installed. It started working after I installed 20 packages matching lib32* . lib32stdc++6 is probably essential, some of the others may be overkill. % aptitude install lib32asound2 lib32asound2-plugins lib32bz2-1.0 lib32cr0 lib32ffi5 lib32gcc1 lib32gmp3 lib32gmpxx4 lib32icu44 lib32ncurses5 lib32ncursesw5 lib32nss-mdns lib32objc2 lib32readline5 lib32readline6 lib32stdc++6 lib32tinfo5 lib32v4l-0 lib32vdpau1 lib32z1 Some solutions might be: 1) Promote the 64 bit release on the download page, so 64-bit users stop downloading the 32-bit build. 2) Have run-mozilla.sh check for this situation, and inform the user how to resolve it. (Although I tend to blindly run ./firefox)

I forgot to mention ia32-libs-gtk. This package was also essential to run 32bit Firefox on 64bit machine.

On Archlinux, I simply downloaded FF and run it's binary: x220:/tmp/firefox$ ./firefox XPCOMGlueLoad error for file /tmp/firefox/libxpcom.so: libxul.so: cannot open shared object file: No such file or directory Couldn't load XPCOM. x220:/tmp/firefox$ ./firefox-bin XPCOMGlueLoad error for file /tmp/firefox/libxpcom.so: libxul.so: cannot open shared object file: No such file or directory Couldn't load XPCOM. x220:/tmp/firefox$ find -name libxpcom.so ./libxpcom.so x220:/tmp/firefox$ ./run-mozilla.sh run-mozilla.sh: Cannot execute . It doesn't work. I do have an existing Firefox install, via the Archlinux package, but this Mozilla distribution should be "self-contained" (preferably statically built!).

Same here. Recent nightly tarballs simply won't run. This is the i686 build on a 32 bit machine.

Also with SeaMonkey nightlies: Good: 20121122003007 http://hg.mozilla.org/mozilla-central/rev/3b71d63eafd5 http://hg.mozilla.org/comm-central/rev/99fd4744910d Bad: 20121123100213 http://hg.mozilla.org/mozilla-central/rev/4d832dcd0be9 http://hg.mozilla.org/comm-central/rev/e2ec99c4e48a Trying to start the program, I get (on stdout+stderr log): XPCOMGlueLoad error for file /usr/local/seamonkey/libxpcom.so: libxul.so: cannot open shared object file: No such file or directory Couldn't load XPCOM.

P.S. I'm on linux64 but setting Hardware to All in the light of comment #16.

(In reply to Tony Mechelynck [:tonymec] from comment #17) > Also with SeaMonkey nightlies: This build is again "startable": Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20.0 Firefox/20.0 SeaMonkey/2.17a1 ID:20121124173313 c-c:90c30f23e058 m-c:3c67034ba39c

I reproduced the same problem with Debian 6.0.5 stable x86_64 with Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20100101 Firefox/17.0 downloaded from the official website. I solved it by installing xulrunner, ia32-libs and ia32-libs-gtk. The way I debugged is by finding that the firefox executable is a 32-bit executable, and it needs xulrunner (for XPCOM), and the 32-bit libraries for running a 32-bit executable.

Broken again on FF18 Downloaded firefox-18.0.tar.bz2 from ftp://ftp.mozilla.org/pub/firefox/releases/18.0/linux-x86_64/en-US/ /usr/local> sudo tar -xf /usr/people/rich/Downloads/firefox-18.0.tar /usr/local> /usr/local/firefox/firefox XPCOMGlueLoad error for file /usr/local/firefox/libxpcom.so: libxul.so: cannot open shared object file: No such file or directory Couldn't load XPCOM. Workaround reinstall FF17

Can confirm this bug for firefox 18.0, german version, 32Bit, Linux. Downloaded here: ftp.mozilla.org/pub/mozilla.org/firefox/releases/18.0/linux-i686/de/ Error message: > firefox XPCOMGlueLoad error for file /opt/MozillaFirefox18_0/libxpcom.so: libxul.so: cannot open shared object file: No such file or directory Couldn't load XPCOM. Workaround: install FF17.0.2esr

Source: http://www.mozilla.org/en-US/firefox/fx/#desktop (popup says firefox-18.0.tar.bz2 file is from http://download.cdn.mozilla.net) Slightly different error (between >>> <<< below) for firefox-18.0 (US 32-bit for Linux) running on CentOS-5.8 system with latest kernel: XPCOMGlueLoad error for file /usr/lib/firefox-18.0/libxpcom.so: >>> libgio-2.0.so.0: <<< cannot open shared object file: No such file or directory Couldn't load XPCOM. However, the same firefox binaries work fine on CentOS-6.3 with latest kernel. xulrunner i386 is present on both machines, so this may be why a different shared library is being flagged. rpmfind.net says libgio-2.0 is contained in glib2-2.22.5-7.el6.i686.rpm, which is on my CentOS-6.3 system. CentOS-5.8 is running glib2-2.12.3-4.el5_3.1 - which apparently doesn't have this library. Upgrading this system to CentOS-6.3 isn't an option due to dependencies by other software. Any ideas?

Latest update firefox-18.0.1 works correctly. Thank You

Had the same error message for seamonkey 2.14.1 and 2.15.1 after installing on a new 64-bit machine. 2.14.1 had worked ok on my previous 32-bit machine. On Mageia (linux) release 2 64-bit, with seamonkey 2.15.1, it is just necessary to install the 32-bit version of xulrunner, and it pulls in all the necessary dependancies (about 20 or so). Then seamonkey 2.15.1 works correctly. xulrunner should be added to the requirements for 64-bit Linux. (at http://www.seamonkey-project.org/releases/seamonkey2.15/#install) (probably would work for FF as well)

I still have the same problem reported in Comment 23: XPCOMGlueLoad error for file /usr/lib/firefox-18.0/libxpcom.so: >>> libgio-2.0.so.0: <<< cannot open shared object file: No such file or directory Couldn't load XPCOM. Latest update firefox-18.0.1 dien't solve it. I'm using Red Hat Enterprise Linux Server Release 5.5 (Tikanga)

I think this bug is only about problem loading libxpcom.so. If you are missing any 3rd party library, e.g. libgio-2.0.so.0 then please install the required package for your system (e.g. this specific file may be in the glib2 package). Mozilla can't solve that for you. But if you can find libgio-2.0.so.0 in a standard system location (e.g. /usr/lib) then please provide more details.

I came across the same bug. Reproduction: Trying to launch SeaMonkey 2.15.2 (downloaded from: http://releases.mozilla.org/pub/mozilla.org/seamonkey/releases/2.15.2/linux-i686/en-US/seamonkey-2.15.2.tar.bz2 ) on the new installed Kubuntu 12.10 AMD64 system (downloaded from: http://mirror.mcs.anl.gov/pub/ubuntu-iso/DVDs-Kubuntu/12.10/release/kubuntu-12.10-desktop-amd64.iso ) SeaMonkey archive was unpacked to /home/dell/Programs/seamonkey directory. Error message while launching SeaMonkey: dell@Dell-Latitude-E6530:~/Programs/seamonkey$ ./seamonkey XPCOMGlueLoad error for file /home/dell/Programs/seamonkey/libxpcom.so: libxul.so: cannot open shared object file: No such file or directory Couldn't load XPCOM. Error message while trying LD_LIBRARY_PATH command: dell@Dell-Latitude-E6530:~/Programs/seamonkey$ LD_LIBRARY_PATH=~/Programs/seamonkey ~/Programs/seamonkey/seamonkey XPCOMGlueLoad error for file /home/dell/Programs/seamonkey/libxpcom.so: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory Couldn't load XPCOM. Very inadequate behaviour for the package that is supposed to run out of the box... :((

Can you see if any hints in bug 723487 fixes your problem? E.g. upgrading glibc. Maybe we should dupe this bug there.

In addition to my comment #28 I did some primitive research. I checked all available SeaMonkey versions and latest Firefox version (18.0.2) from http://releases.mozilla.org/pub/mozilla.org/seamonkey/releases/ All of them failed with the same error message (see above in comment #28). I should say that all of checked versions were 32-bit. At the same time when I downloaded Firefox 64-bit version 18.0.2 from the same source it worked well. I also tested SeaMonkey 64-bit version 2.16 beta 4 from ftp://ftp.mozilla.org/pub/seamonkey/candidates/2.16b4-candidates/build1/linux-x86_64/en-US/ and it launched and worked as well. So I made a conclusion that SeaMonkey and Firefox 32-bit versions failure on Kubuntu 12.10 AMD64 seemed to be caused by some program dependencies of different architectures (32/64 bits). Next step I tried proved this assumption. (Thanks :aceman for referencing to bug 723487 topic). Command LD_DEBUG=libs /home/dell/Programs/seamonkey/seamonkey showed that 32-bit SeaMonkey while being launched looked for some dynamic libraries among 32-bit directories (/usr/lib/i386-linux-gnu for example) and 64-bit SeaMonkey among 64-bit directories (/usr/lib/x86_64-linux-gnu correspondingly). As appeared Kubuntu 12.10 AMD64 distribution contains a number of libraries needed for SeaMonkey and Firefox only in their 64-bit versions. In several iterations I added via Synaptic from reps the following requested 32-bit version packages: libdbus-glib-1-2:i386 (ver 0.100-1) libpango1.0-0:i386 (ver 1.30.1-0ubuntu3) libgtk2.0-0:i386 (ver 2.24.13-0ubuntu2) After that SeaMonkey finally loaded with double warning message: (seamonkey:7974): Gtk-WARNING **: Unable to locate theme engine in module_path: "oxygen-gtk" I hope this information will help the SeaMonkey developers to tune next releases packages properly so they really could work out of the box. Unfortunately the magic described above in my opinion is not for ordinary users who want to work on Linux with the programs which they have already used to. I would also wish that the developers and maintainers have enough resources to introduce long-awaited 64-bit SeaMonkey.

In reply to comment #30: I don't know Kubuntu, but on openSUSE (which is what I use) many packages come in pairs (both for architecture x86_64): packagename (for 64-bit programs) and packagename-32bit (for 32-bit programs running on this 64-bit OS). If I want full capabilities for both 64-bit and 32-bit programs I have to install both packages. Maybe you should check the list of your installed vs. available packages to see if Kubuntu doesn't do something similar? BTW: 64-bit Linux SeaMonkey is already being compiled at Mozilla for all four of trunk, aurora, beta and release code branches; it is just not touted as official because there are too few users (a chicken-and-egg problem, and IMHO even some kind of vicious circle). There is a link for the "release" build under "Contributed builds" at the bottom of the "Other Systems ans Languages" page linked from the bottom line of the big green button at http://www.seamonkey-project.org/ Similarly, for the "beta" build, follow the link saying "the beta is available for free download", scroll to the bottom, and you'll find a link to a 64-bit build under "Contributed builds". For Aurora and Trunk, here are the links: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-aurora/?C=M;O=D http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/?C=M;O=D The ?C=M;O=D at the end is optional; it means "sort the FTP directory latest-first". Just be sure (of course) to download the linux-x86_64 .tar.bz2 (and I recommend also the corresponding .txt, it tells you exactly from which comm-{aurora|central} and mozilla-{aurora|central} changesets the build was made), not those for some other architecture. And I repeat, all four of the above series of builds are built on Mozilla machines and from the official Mozilla source, even those listed as "Contributed".

Similar behavior on OSX 10.8 and FFv18 Created a symlink: sudo ln -s /Applications/Firefox.app/Contents/MacOS/firefox /usr/local/bin/firefox and yet error running from the symlink: > firefox XPCOMGlueLoad error 4:0 for file /usr/local/bin/libxpcom.dylib: image not found Couldn't load XPCOM. (entering the original location of the file, it loads fine)

2 Tony Mechelynck (In reply to Tony Mechelynck [:tonymec] from comment #31) > BTW: 64-bit Linux SeaMonkey is already being compiled at Mozilla for all > four of trunk, aurora, beta and release code branches; it is just not touted > as official because there are too few users (a chicken-and-egg problem, and > IMHO even some kind of vicious circle). > > And I repeat, all four of the above series of builds are built on Mozilla > machines and from the official Mozilla source, even those listed as > "Contributed". Thanks!

Same problem, showing in firefox-22.0a1.en-US.linux-i686.tar.bz2 Attached is LD_DEBUG=all output

On host big41 running 64 bit openSUSE 13.1M4+, and openSUSE 12.3, both with KDE 4.1x, 64 bit builds from mozilla.org FTP: Working: SeaMonkey rv20 SeaMonkey rv23 Failing: Firefox 21 Firefox 23 LC_LIBRARY_PATH=`pwd` ./firefox -P <profilename> XPCOMGlueLoad error for file /usr/local/ffcur/libxpcom.so: libXrender.so.1: cannot open shared object file: No such file or directory Couldn't load XPCOM. http://www.mozilla.org/en-US/firefox/21.0/system-requirements/ says GLib 2.22 or higher is required, but no such package seems to exist in the standard openSUSE repositories. libglib-2_0-0-2.34.3-2.1.1 is installed on 12.3, 2.37.5-1.1 on 13.1M4.

Results on same big41 host booted to 64 bit Fedora 19 and KDE 4.10.5 with export MOZ_NO_REMOTE=1 included in ~/.bashrc: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0; Build ID: 20130805152501 OK Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0; Build ID: 20130201065344 OK Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0; Build ID: 20130307023931 OK Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0; Build ID: 20130409194949 OK FF rv21 FAILS error while loading shared libraries: libstdc++.so.6: cannot open... FF rv22 FAILS error while loading shared libraries: libstdc++.so.6: cannot open... FF rv23 FAILS error while loading shared libraries: libstdc++.so.6: cannot open... Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0; Build ID: 20130829135643 OK Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0; Build ID: 20130901030218 OK

(In reply to Bodhi B Roy from comment #20) > I reproduced the same problem with > Debian 6.0.5 stable x86_64 with Mozilla/5.0 (X11; Linux i686 on x86_64; > rv:17.0) Gecko/20100101 Firefox/17.0 downloaded from the official website. > > I solved it by installing xulrunner, ia32-libs and ia32-libs-gtk. > > The way I debugged is by finding that the firefox executable is a 32-bit > executable, and it needs xulrunner (for XPCOM), and the 32-bit libraries for > running a 32-bit executable. I also had same problem after a difficult upgrade from Mageia 2 to Mageia 3, 64bit. I had to remove many 32bit packages to allow the upgrade to procede. Afterwards Seamonkey 2.17.1, that worked well before the upgrade, failed to start with the XULGlueFile error message. By installing xulrunner + libxulrunner 14.0.1, this error message disappeared. Subsequent installation of many 32bit gtk-related packages progressively got rid of other error messages that appeared, and allowed Seamonkey to start normally. Since then I noticed that a 64bit compile of Seamonkey is available further down on the download page, which I will use for future Seamonkey installs to avoid this sort of problem. (It might still need xulrunner, but not the other 32bit packages which are otherwise unnecessary.) Interesting that the Seamonkey requirement page does not mention xulrunner. It took a while before I realised that it was required. At least for installing 32bit Seamonkey on 64bit Linux.

XPCOMGlueLoad error for file /opt/aurora/libxul.so: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory Couldn't load XPCOM. opensuse 13.1 RC1 Aurora 26

lain@EVA:~$ /opt/firefox/firefox XPCOMGlueLoad error for file /opt/firefox/libxul.so: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory Couldn't load XPCOM. Ubuntu 13.10 with gnome shell 3.10

I still have this issue with Iceweasel on Raspberry Pi/Debian 8.0. $ uname -a Linux raspberrypi 4.4.13+ #894 Mon Jun 13 12:43:26 BST 2016 armv6l GNU/Linux $ dpkg -l | grep iceweasel ii iceweasel 45.2.0esr-1~deb8u1 all Web browser based on Firefox - Transitional package