Closed Bug 723487 Opened 13 years ago Closed 12 years ago

libxul.so: cannot open shared object file: No such file or directory

Categories

(Toolkit :: Startup and Profile System, defect)

Product:
Toolkit
Component:
Startup and Profile System
Version:
10 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
RESOLVED FIXED
Project Flags:
blocking-kilimanjaro -

People

(Reporter: amnesia, Unassigned)

References

Details

Attachments

(3 files)

Strace when I try to start the binary
90.08 KB, text/plain
Details
OUtput of: LD_DEBUG=libs ~/firefox/firefox
7.50 KB, text/plain
Details
Trace of FF 13.0.1
27.53 KB, text/plain
Details 
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Build ID: 20111220165912

Steps to reproduce:

amnesia@Box:~/firefox$ ./firefox 


Actual results:

XPCOMGlueLoad error for file /home/amnesia/firefox/libxpcom.so: 
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM. 


Expected results:

Firefox should start normally

*Note* FF 10< works fine.
Summary: Can't start FF10 → "libxul.so: cannot open shared object file"
just extracted the firefox-10.0.tar.bz2 file and tried to execute the wrapper. My system is running on native x86_64, and 2.6.35-14
Summary: "libxul.so: cannot open shared object file" → libxul.so: cannot open shared object file: No such file or directory

    
    

    
  
Duplicate of bug 704298?

There is also bug 685433 which might provide information.

    
    

    
  
Don't think so, I'm sure I'm running the pure 64 bit release, and also sure that my permissions are sufficient. (also tried it as root).
Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit
QA Contact: untriaged → startup

    
  
Severity: normal → blocker

    
    

    
  
Does /home/amnesia/firefox/libxpcom.so and libxul.so exist? If so, can you please run

LD_DEBUG=libs ~/firefox/firefox And see if there's anything interesting in the output?

If libxpcom.so doesn't exist, then there is a packaging/installation issue.

    
    

    
  


  

    
    

    
  
Yes it's definitely there. The following files are present when I unpacked the package.

amnesia@Candycase:~$ ls -l ~/firefox/
total 37744
-rw-r--r-- 1 amnesia amnesia      825 Jan 29 15:13 Throbber-small.gif
-rw-r--r-- 1 amnesia amnesia     2149 Jan 29 15:12 application.ini
-rw-r--r-- 1 amnesia amnesia    11678 Jan 29 15:12 blocklist.xml
drwxr-xr-x 3 amnesia amnesia     4096 Jan 29 16:47 chrome
-rw-r--r-- 1 amnesia amnesia       36 Jan 29 16:47 chrome.manifest
drwxr-xr-x 2 amnesia amnesia     4096 Jan 29 16:47 components
-rwxr-xr-x 1 amnesia amnesia   148264 Jan 29 15:13 crashreporter
-rw-r--r-- 1 amnesia amnesia      615 Jan 29 16:47 crashreporter-override.ini
-rw-r--r-- 1 amnesia amnesia     3868 Jan 29 16:47 crashreporter.ini
drwxr-xr-x 3 amnesia amnesia     4096 Jan 29 16:47 defaults
-rw-r--r-- 1 amnesia amnesia      142 Jan 29 15:12 dependentlibs.list
drwxr-xr-x 3 amnesia amnesia     4096 Jan 29 15:13 extensions
-rwxr-xr-x 1 amnesia amnesia    61544 Jan 29 15:13 firefox
-rwxr-xr-x 1 amnesia amnesia    61544 Jan 29 15:13 firefox-bin
drwxr-xr-x 2 amnesia amnesia     4096 Jan 29 15:13 icons
-rw-r--r-- 1 amnesia amnesia      478 Jan 29 15:13 libfreebl3.chk
-rwxr-xr-x 1 amnesia amnesia   426448 Jan 29 15:13 libfreebl3.so
-rwxr-xr-x 1 amnesia amnesia     8040 Jan 29 15:13 libmozalloc.so
-rwxr-xr-x 1 amnesia amnesia   667952 Jan 29 15:13 libmozsqlite3.so
-rwxr-xr-x 1 amnesia amnesia   219888 Jan 29 15:13 libnspr4.so
-rwxr-xr-x 1 amnesia amnesia  1071928 Jan 29 15:13 libnss3.so
-rwxr-xr-x 1 amnesia amnesia   476672 Jan 29 15:13 libnssckbi.so
-rw-r--r-- 1 amnesia amnesia      478 Jan 29 15:13 libnssdbm3.chk
-rwxr-xr-x 1 amnesia amnesia   153296 Jan 29 15:13 libnssdbm3.so
-rwxr-xr-x 1 amnesia amnesia   123712 Jan 29 15:13 libnssutil3.so
-rwxr-xr-x 1 amnesia amnesia    17816 Jan 29 15:13 libplc4.so
-rwxr-xr-x 1 amnesia amnesia    13880 Jan 29 15:13 libplds4.so
-rwxr-xr-x 1 amnesia amnesia   160872 Jan 29 15:13 libsmime3.so
-rw-r--r-- 1 amnesia amnesia      478 Jan 29 15:13 libsoftokn3.chk
-rwxr-xr-x 1 amnesia amnesia   242336 Jan 29 15:13 libsoftokn3.so
-rwxr-xr-x 1 amnesia amnesia   212152 Jan 29 15:13 libssl3.so
-rwxr-xr-x 1 amnesia amnesia    16640 Jan 29 15:13 libxpcom.so
-rwxr-xr-x 1 amnesia amnesia 27734720 Jan 29 15:13 libxul.so
-rwxr-xr-x 1 amnesia amnesia    61344 Jan 29 15:13 mozilla-xremote-client
-rw-r--r-- 1 amnesia amnesia  6388648 Jan 29 16:47 omni.ja
-rw-r--r-- 1 amnesia amnesia      135 Jan 29 15:12 platform.ini
-rwxr-xr-x 1 amnesia amnesia    49440 Jan 29 15:13 plugin-container
-rw-r--r-- 1 amnesia amnesia     1713 Jan 29 16:47 precomplete
-rw-r--r-- 1 amnesia amnesia    35030 Jan 29 15:12 removed-files
-rwxr-xr-x 1 amnesia amnesia    10380 Jan 29 15:12 run-mozilla.sh
drwxr-xr-x 2 amnesia amnesia     4096 Jan 29 16:47 searchplugins
-rw-r--r-- 1 amnesia amnesia        3 Jan 29 16:47 update.locale
-rwxr-xr-x 1 amnesia amnesia   139136 Jan 29 15:13 updater
-rw-r--r-- 1 amnesia amnesia      105 Jan 29 16:47 updater.ini

file ~/firefox/libxpcom.so: /home/amnesia/firefox/libxpcom.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

    
    

    
  
Experiencing the same issue with: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/10.0.1/linux-x86_64/en-GB/firefox-10.0.1.tar.bz2. Compiled FF10.1 myself though and this release does work fine.

    
    

    
  
Probably not a blocker but I see a couple of dups or near dups so flagging as ?
Status: UNCONFIRMED → NEW
blocking-kilimanjaro: --- → ?
Ever confirmed: true

    
  
blocking-kilimanjaro: ? → -

    
    

    
  
Not a recent regression, and not enough dupes to track for release of FF either.

    
    

    
  
FYI: This bug is a duplicate of bug 762621

    
    

    
  
> FYI: This bug is a duplicate of bug 762621
As I understand it there are two different problems with the same initial symptoms. One is about a missing library, the other is about missing symbols.

    
    

    
  
>> One is about a missing library, the other is about missing symbols.

The seem the same to me (albeit one is for firefox and the other for thunderbird). It is the missing symbol that causes a library load failure.

With the "wrong" dependents.list file in place for thunderbird 13 (see bug 762621), LD_DEBUG=libs output ends up showing:

XPCOMGlueLoad error for file /local/i586/thunderbird/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
      4006:     /local/i586/thunderbird/thunderbird: error: symbol lookup error: undefined symbol: NS_GetFrozenFunctions (fatal)

which looks just like the problem reported here.

Mind you, I never had a problem with FF10, which woudl have been on the same system as where TB13 failed.

    
    

    
  
Same problem here on 32bit x86:

>./firefox
XPCOMGlueLoad error for file /opt/firefox/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

>LD_LIBRARY_PATH=`pwd` ./firefox 
XPCOMGlueLoad error for file /opt/firefox/libxpcom.so:
libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

DBUS isn't installed and should be optional (FF requirements page).

    
    

    
  

      
      
      
      

        Attached file
          
        Trace of FF 13.0.1
        — 
      

    


  

    
    

    
  
Similar issue with firefox-13.0.1-cy. ~/.xsession-errors contains:

lib/firefox/plugin-container: error while loading shared libraries: libxpcom.so: cannot open shared object file: No such file or directory

Note that I was running exactly the same binary with no problems prior to reboot.

Application info from application.ini:

[App]
Vendor=Mozilla
Name=Firefox
Version=13.0.1
BuildID=20120614114901
SourceRepository=http://hg.mozilla.org/releases/mozilla-release
SourceStamp=f48d675ffa9f
ID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}

[Gecko]
MinVersion=13.0.1
MaxVersion=13.0.1

[XRE]
EnableProfileMigrator=1
EnableExtensionManager=1

[Crash Reporter]
Enabled=1
ServerURL=https://crash-reports.mozilla.com/submit?id={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&version=13.0.1&buildid=20120614114901

System info:

Linux 3.4.4-2-ARCH #1 SMP PREEMPT Sun Jun 24 18:59:47 CEST 2012 x86_64 GNU/Linux

The version I have installed through my package manager works fine. I usually use Mozilla's as the language packs don't work for my language.

Apologies for reporting this as bug 771381. I did search but couldn't find anything. I was looking for a problem with the -cy localisation as the US English version seemed to be working. (But maybe that's a build difference in my distro vs. Mozilla's own binaries.)

    
    

    
  
Here's a thread on Arch I started to discuss this issue:
https://bbs.archlinux.org/viewtopic.php?pid=1127042#p1127042

Thread includes output from running:
LD_LIBRARY_PATH=/usr/local/lib/firefox:/lib:/usr/lib strace -e trace=open -o ff-ld-mwy.strace firefox

(Without setting the path, it fails much quicker.)

The suggestion there is that the latest upgrade of glibc (2.16.0) on Arch is somehow responsible for the issue. Since Arch's firefox has no problems, I assume this is some sort of difference in the builds.

I don't consider downgrading glibc a satisfactory solution because I'm sure keeping it downgraded will cause much greater breakage some time down the line.

Another suggestion is removing some of the libraries from Mozilla's build. Would this be a good approach and, if so, which ones should be removed?

    
    

    
  
I found a work around with a good deal of help from the Arch forums. This doesn't require downgrading system software but relies on hacking Mozilla's install and setting LD_LIBRARY_PATH.

I use stow to manage most software in /usr/local/. So I copied /usr/local/stow/firefox-13.0.1-cy to /usr/local/stow/firefox-13.0.1-cy-profi, unstowed the first and edited and stowed the second. Basically, I removed a bunch of libraries:

$ diff -rq firefox-13.0.1-cy*
Only in firefox-13.0.1-cy/lib/firefox: libfreebl3.chk
Only in firefox-13.0.1-cy/lib/firefox: libfreebl3.so
Only in firefox-13.0.1-cy/lib/firefox: libnss3.so
Only in firefox-13.0.1-cy/lib/firefox: libnssckbi.so
Only in firefox-13.0.1-cy/lib/firefox: libnssdbm3.chk
Only in firefox-13.0.1-cy/lib/firefox: libnssdbm3.so
Only in firefox-13.0.1-cy/lib/firefox: libnssutil3.so
Only in firefox-13.0.1-cy/lib/firefox: libsmime3.so
Only in firefox-13.0.1-cy/lib/firefox: libsoftokn3.chk
Only in firefox-13.0.1-cy/lib/firefox: libsoftokn3.so
Only in firefox-13.0.1-cy/lib/firefox: libssl3.so

Essentially, this is everything to do with nss.

I can then start Mozilla's build with:

LD_LIBRARY_PATH=/usr/local/lib/firefox firefox

and I have firefox in Welsh again!

    
    

    
  
I think this is a platform issue and not specifice to Firefox, Thunderbird, or SeaMonkey. I'm using Ubuntu Unity (sorry I don't have the number). It came with Firefox and Thunderbird installed. I could not install SeaMonkey using the package manager, so I downloaded the tar.gzip2 file. I get the same errors. Is there possibly an issue with libraries already being loaded? Does one or the other lock the libraries? Is there an issue with "installing" these with existing versions of one or another already installed? Can someone just release these as deb and rpm packages so the system can check for dependencies and conflicts?

    
    

    
  
> deb and rpm packages
Are the responsibility of the various distro maintainers. We don't control what they do or don't do or how/when they do it.

    
    

    
  
For reference, I'm getting this with the mozilla provided thunderbird 15,
while the distro provided rpms work fine.

$ ./thunderbird
XPCOMGlueLoad error for file /home/padraig/Downloads/thunderbird/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

    
    

    
  
I also see this problem with the release tarball of FF 17a2 on Fedora 17.

    
    

    
  
Try downloading Firefox manually from ftp://ftp.mozilla.org/pub, and make sure to choose the 64 bit version. This just happened to me, and i think that it is a result of the Mozilla website failing to recognize that I use a 64 bit version of Linux, and so it offered me to download the 32 bit version.

    
    

    
  
I got this with 18.0a1 nightly downloaded Sep 21st.  32 bit running on 32 bit.  glibc 2.12

    
    

    
  
(In reply to Ian Nartowicz from comment #26)
> I got this with 18.0a1 nightly downloaded Sep 21st.  32 bit running on 32
> bit.  glibc 2.12

Firefox Nightlies since 2012-09-21 seem to use a new GNU extension (cf. Bug 799886) which is not supported by "older" dynamic linkers/loaders, e.g. /lib64/ld-2.9.so does not seem to support it.

What version do your binutils report (try nm --version). Can you check for unknown symbol types in libxul.so with

nm -Ca libxul.so |grep ' ? '

    
    

    
  
Binutils says 2.20.

nm -Ca libxul.so |grep ' ? ' says:
nm: 'libxul.so': No such file

    
    

    
  
I followed the suggestion in comment 25 and obtained 64 bit binaries; all of my earlier problems described herein disappeared.

    
    

    
  
Sorry, running nm and correctly specifying the path to libxul.xo gives me no output, presumably no unknown symbols.

    
    

    
  
(In reply to Ian Nartowicz from comment #31)
> Sorry, running nm and correctly specifying the path to libxul.xo gives me no
> output, presumably no unknown symbols.

This is the intended outcome. Could you re-run nm on the previous libxul.so which did not start?

    
    

    
  
(In reply to Stefan from comment #27)
> nm -Ca libxul.so |grep ' ? '

In order to allow for stripped files and different versions of binutils one should use

   nm -CD libxul.so |grep ' \(?\|u\) '

When applied to nightly 2012-09-20-03-05-43-mozilla-central there is no output (expected). When applied to nightlies starting with 2012-09-21-03-06-01-mozilla-central the command outputs lines which indicates the use of the GNU extension.

    
    

    
  
Similar reports (some might be packaging issues of distros): bug 803705, bug 804939

    
    

    
  
(In reply to Andre Klapper from comment #34)

Quote from Bug 804939: "openSuse 11.1 saw its end of life on 13 January 2011" Support continued under the name "Evergreen" until January 2012 or so. Bug 804939 is a duplicate because OpenSUSE 11.1 cannot execute libxul.so due to the GNU extension used.

    
    

    
  
Having this kind of bug with Mozilla Thunderbird development version, using up to date trunk code.

[fred@fredo-arch thunderbird]$ ./thunderbird
XPCOMGlueLoad error for file /home/fred/logs/mail/objdir-tb/mozilla/dist/thunderbird/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

And of course, libxul.so can be listed

[fred@fredo-arch thunderbird]$ ls -alh *.so
-rwxr-xr-x 1 fred users 436K  8 nov.  15:50 libfreebl3.so
-rwxr-xr-x 1 fred users 215K  8 nov.  15:50 libldap60.so
-rwxr-xr-x 1 fred users  11K  8 nov.  15:50 libldif60.so
-rwxr-xr-x 1 fred users 8,0K  8 nov.  15:50 libmozalloc.so
-rwxr-xr-x 1 fred users 532K  8 nov.  15:50 libmozsqlite3.so
-rwxr-xr-x 1 fred users 238K  8 nov.  15:50 libnspr4.so
-rwxr-xr-x 1 fred users 1,1M  8 nov.  15:50 libnss3.so
-rwxr-xr-x 1 fred users 570K  8 nov.  15:50 libnssckbi.so
-rwxr-xr-x 1 fred users 142K  8 nov.  15:50 libnssdbm3.so
-rwxr-xr-x 1 fred users 153K  8 nov.  15:50 libnssutil3.so
-rwxr-xr-x 1 fred users  18K  8 nov.  15:50 libplc4.so
-rwxr-xr-x 1 fred users  13K  8 nov.  15:50 libplds4.so
-rwxr-xr-x 1 fred users  21K  8 nov.  15:50 libprldap60.so
-rwxr-xr-x 1 fred users 157K  8 nov.  15:50 libsmime3.so
-rwxr-xr-x 1 fred users 233K  8 nov.  15:50 libsoftokn3.so
-rwxr-xr-x 1 fred users 234K  8 nov.  15:50 libssl3.so
-rw-r--r-- 1 fred users  16K  8 nov.  15:50 libxpcom.so
-rwxr-xr-x 1 fred users  42M  8 nov.  15:50 libxul.so

    
    

    
  
Bug 805407 which I reported for Firefox 18 with Mandriva 2010 has been marked as a duplicate of this bug. As suggested, I tried the solution in Comment 25, but it would not work for me since I have a 32 bit machine. Is there any other solution I can try to get round this bug?

    
    

    
  
Okay I can confirm. 

1. First I downloaded the thunderbird from the main site, by clicking download. And it didnt work with the error
libxul.so: cannot open shared object file: No such file or directory

Then I downloaded from the ftp site, like mentioned below. And it works now.
ftp://ftp.mozilla.org/pub/thunderbird/releases/latest/linux-x86_64/en-GB/

    
    

    
  
I am having the same issue with firefox 17.0 on a 32 bit debian squeeze (6.0.6) system. I have tried executing with the wrapper script. The system is a primitive "barebones" install of debian and I am not missing any packages. Outcome is the same as root or normal user.

Exact output:
XPCOMGlueLoad error for file /home/thims/firefox/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

    
    

    
  
I observe this bug with Mandriva 2010, but not with Mageia 2. Could it be that Firefox is now only compatible with very recent versions of Linux?

    
    

    
  
Mike, looks like we no longer support ancient libstdc++. We should either fix this or move to a newer libstc++/libc in our build env.

./libxul.so: undefined symbol: _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE
Couldn't load XPCOM.

    
    

    
  
Firefox 17.0.1 32-bits build:
$ objdump -T libxul.so |grep _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE
01c2fb90  w   DO .bss	00000010  Base        _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE

Firefox 17.0.1 64-bits build:
$ objdump -T libxul.so |grep _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE
0000000002a64580  w   DO .bss	0000000000000020  Base        _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE

In both cases, that symbol is defined (although weak). There's no reason this should fail to run.

Can one of you run with LD_DEBUG=all LD_DEBUG_OUTPUT=/path/to/some/file and attach that file here?

    
    

    
  
FWIW, I can't reproduce on debian squeeze with the Firefox 17.0.1 builds, neither on 32-bits nor 64-bits.

    
    

    
  
(In reply to Mike Hommey [:glandium] from comment #44)
> FWIW, I can't reproduce on debian squeeze with the Firefox 17.0.1 builds,
> neither on 32-bits nor 64-bits.

I observe this bug only with Firefox 18 and above.

    
    

    
  
(In reply to weliot from comment #45)
> (In reply to Mike Hommey [:glandium] from comment #44)
> > FWIW, I can't reproduce on debian squeeze with the Firefox 17.0.1 builds,
> > neither on 32-bits nor 64-bits.
> 
> I observe this bug only with Firefox 18 and above.

So, I can confirm, but then this has nothing to do with the original report.

    
    

    
  
(In reply to Mike Hommey [:glandium] from comment #46)
> So, I can confirm, but then this has nothing to do with the original report.

Actually, all I can confirm is the use of the GNU extension for the unique symbols, but the binary still runs on debian squeeze.

    
    

    
  
The GNU extension in question is there since glibc 2.11 (which debian squeeze has)

    
    

    
  
Taking the list of gtk/glib compatibility from bug 772563 comment 13, and considering we settled on compatibility with gtk 2.18, it means we support RHEL6, opensuse 11.2, sles 11sp1, debian squeeze, and a quite old fedora. All of which come with at least glibc 2.11. So I wouldn't expect these symbols to be a problem where gtk is not one. That being said, the gtk 2.18 requirement might be coming later than 18 (probably 19). I don't think it's worth worrying for six weeks.

What we however need is a better error handling.

    
    

    
  
(In reply to Mike Hommey [:glandium] from comment #46)
> (In reply to weliot from comment #45)
> > (In reply to Mike Hommey [:glandium] from comment #44)
> > > FWIW, I can't reproduce on debian squeeze with the Firefox 17.0.1 builds,
> > > neither on 32-bits nor 64-bits.
> > 
> > I observe this bug only with Firefox 18 and above.
> 
> So, I can confirm, but then this has nothing to do with the original report.

Well, that is what I thought too, but when I reported a new bug for Firefox 18 with Mandriva 2010 (Bug 805407) it was marked as a duplicate of this bug.

    
    

    
  
Seems to be getting worse.  Firefix 17 started to work when the beta was released, but 18 beta 3 still not running.

    
    

    
  
(In reply to Ian Nartowicz from comment #51)
> Seems to be getting worse.  Firefix 17 started to work when the beta was
> released, but 18 beta 3 still not running.

What glibc version? What does "LD_DEBUG=all firefox" say?

    
    

    
  
This is the error that Puppy linux spits out when you don't have dbus , dbus-glib installed. See the installation procedure here : http://www.murga-linux.com/puppy/viewtopic.php?t=46390

    
    

    
  
glibc?  Not glib?  glib is 2.22, glibc is 2.10.1.

I found this in LD_DEBUG=files:
/opt/firefox18/libxul.so: error: symbol lookup error: undefined symbol: _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE (fatal)

    
    

    
  
(In reply to Ian Nartowicz from comment #55)
> glibc?  Not glib?  glib is 2.22, glibc is 2.10.1.

What is your distro?

(and yes, I do expect glibc 2.10 to be failing. But all supported systems should have at least 2.11)

    
    

    
  
Thanks!  Upgrading glibc from 2.10 to 2.11 (2.11.1, latest Lucid package) fixed it, fingers crossed, for 18 beta at least.  I'll try nightlies later.

2.10 is really not very old, and it isn't listed in the system requirements for Firefox 18.0:
http://www.mozilla.org/en-US/firefox/18.0/system-requirements/

    
    

    
  
After upgrading Firefox 17.0.1 ESR to 17.0.2 ESR, it stopped working for me as well:

tglase@tglase:~ $ feistermops170                                               
XPCOMGlueLoad error for file /usr/feistermops/170/firefox/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

This is absolutely a showstopper, especially to change this in the micro version of a long-term supported release. Please fix this *ASAP*!

OS: Kubuntu Hardy (8.04), and no, this cannot be upgraded

    
    

    
  
A bit more details: i386, *not* amd64 as shown in the bug header, and using the official binaries from the Mozilla website.

A showstopper regression like that *within* an ESR series is not good.

    
    

    
  
Anyone who was able to reproduce this bug with Firefox 17.0.2esr please try the new candidate builds:

ftp://ftp.mozilla.org/pub/firefox/nightly/17.0.2esr-candidates/build3/

    
    

    
  
Thanks Anthony, that fixes the problem for me.

But this basically means that the 17ESR “series” is (and will be?) the last series to run on Kubuntu Hardy, right? (I guess we can live with that, considering it’s an ESR.)

    
    

    
  
(In reply to Thorsten Glaser from comment #61)
> Thanks Anthony, that fixes the problem for me.
> 
> But this basically means that the 17ESR “series” is (and will be?) the last
> series to run on Kubuntu Hardy, right? (I guess we can live with that,
> considering it’s an ESR.)

An alternative solution may be to use Portable Firefox with Wine.

    
    

    
  
It’s a good thing my coffee cup was empty. I surely hope you were joking, right? (’sides, lots of plugins packaged on the Linux distro side, here.)

    
    

    
  
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #60)
> Anyone who was able to reproduce this bug with Firefox 17.0.2esr please try
> the new candidate builds:
> 
> ftp://ftp.mozilla.org/pub/firefox/nightly/17.0.2esr-candidates/build3/

The 64 bit version of works on 64 bit Ubuntu Hardy (server) for me. Thanks.

    
    

    
  
Only partly joking! But as you point out, it's the Linux plugins thing which is preventing me pursuing the Wine route.

    
    

    
  
… if it’s just the plugin issue preventing you from doing that, you have my sincerest condolences.

    
    

    
  
Haha, thanks!

    
    

    
  
(In reply to Thorsten Glaser from comment #61)
> Thanks Anthony, that fixes the problem for me.

This release is now live and available as an update to existing Firefox 17esr users. To those of you who are currently using systems with the affected GCC versions, you'll have until Firefox 26 to figure out an upgrade path (~48 weeks) at which point Firefox 17esr will be desupported and will no longer receive security updates. 

I'm not sure what the solution is, but this bug isn't the right platform to have that discussion. I suppose the Enterprise mailing list might be the best place.

Anyway, can we now mark this bug resolved?

    
    

    
  
Mh, I think that’s fair.

    
    

    
  
Marking this bug resolved fixed. Please reopen if this remains broken for you using Firefox 17.0.2esr.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED

    
    

    
  
I downloaded the latest version of Firefox 17 ESR from https://download.mozilla.org/?product=firefox-17.0.2esr&os=linux&lang=nl and unpacked it in /opt/firefox. Running CentOS 6.3 x86_64 with all necessary i686 libs installed.

First time running it I get the error:

[bastiaan@baardmans ~]$ /opt/firefox/firefox
XPCOMGlueLoad error for file /opt/firefox/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

libxul.so is just there in the /opt/firefox directory, same directory as the binary reside.

After running:
LD_LIBRARY_PATH=/opt/firefox:/usr/lib:/usr/local/lib /opt/firefox/firefox
everything works.
Seems it has triggered /opt/firefox/*.so to be taken up in the ldd cache, because after this just running /opt/firefox/firefox without setting the LD_LIBRARY_PATH works as well.
Don't know if a linux OS is supposed to find libraries in the same directory as the executable, but else this should be fixed in the /opt/firefox/firefox wrapper.
And this note can be useful for other people experiencing the 17-ESR distro from downloads.mozilla.org doesn't work out-of-the-box.

    
    

    
  
(In reply to Bastiaan Welmers from comment #71)
> After running:
> LD_LIBRARY_PATH=/opt/firefox:/usr/lib:/usr/local/lib /opt/firefox/firefox
> everything works.
> Seems it has triggered /opt/firefox/*.so to be taken up in the ldd cache,
> because after this just running /opt/firefox/firefox without setting the
> LD_LIBRARY_PATH works as well.

Which "ldd cache"?

    
    

    
  
Firefox doesn't rely on LD_LIBRARY_PATH to find its libraries, it loads them with the explicit complete path, so in your case, it "manually" loads /opt/firefox/lib*.so. There must have been something else wrong on your system.

    
    

    
  
The problem happens with Firefox 18.0.1 x64 on a Mandriva 2009.1 x64 based system and indeed LD_LIBRARY_PATH makes a difference.

Without LD_LIBRARY_PATH

[gh@localhost ~]$ 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.

With LD_LIBRARY_PATH

[gh@localhost ~]$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/firefox/ /usr/local/firefox/firefox
XPCOMGlueLoad error for file /usr/local/firefox/libxpcom.so:
/usr/local/firefox/libxul.so: undefined symbol: _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE
Couldn't load XPCOM.

The glibc version is 2.9.

The problem does NOT occur with firefox-17esr .

    
    

    
  
(In reply to Gustavo Homem from comment #74)
> The problem happens with Firefox 18.0.1 x64 on a Mandriva 2009.1 x64 based
> system and indeed LD_LIBRARY_PATH makes a difference.
> 
> Without LD_LIBRARY_PATH
> 
> [gh@localhost ~]$ 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.
> 
> With LD_LIBRARY_PATH
> 
> [gh@localhost ~]$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/firefox/
> /usr/local/firefox/firefox
> XPCOMGlueLoad error for file /usr/local/firefox/libxpcom.so:
> /usr/local/firefox/libxul.so: undefined symbol:
> _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE
> Couldn't load XPCOM.
> 
> The glibc version is 2.9.
> 
> The problem does NOT occur with firefox-17esr .

The same here: firefox-17.0.2esr works without problems, firefox-18.0.2 does not.


$ ./firefox -P
XPCOMGlueLoad error for file /home/bamboo/firefox-18.0.2-x64/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

$ LD_LIBRARY_PATH=. ./firefox -P
XPCOMGlueLoad error for file /home/bamboo/firefox-18.0.2-x64/libxpcom.so:
./libxul.so: undefined symbol: _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE
Couldn't load XPCOM.


The error occurs with 32 and 64-bit binaries from http://www.mozilla.org/en-US/firefox/all/

2 lines that changed in Firefox 18 compared to Firefox 17 when I execute ldd on the libs:

$ ldd libxpcom.so
ldd: warning: you do not have execution permission for `./libxpcom.so'

$ ldd libxul.so
./libxul.so: /usr/lib64/libssl3.so: version `NSS_3.14' not found (required by ./libxul.so)

So the execution bit is missing in libxpcom.so (but setting it seems to change nothing).
And libxul.so seems to have a new requirement to NSS_3.14.

In addition, there are 3 new folders in modules: commonjs identity services.


$ uname -a
Linux suse2 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 0

    
    

    
  
I have trouble with firefox 19.0

$ uname -a
Linux bi-desktop 2.6.28-19-generic #66-Ubuntu SMP Sat Oct 16 17:39:04 UTC 2010 i686 GNU/Linux

$LD_LIBRARY_PATH=`pwd` ./firefox
XPCOMGlueLoad error for file /home/user/firefox/libxpcom.so:
/home/user/firefox/libxul.so: undefined symbol: _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE
Couldn't load XPCOM.

====
./firefox
XPCOMGlueLoad error for file /home/user/firefox/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

    
    

    
  
I have trouble with firefox 19.0

$ uname -a
Linux bi-desktop 2.6.28-19-generic #66-Ubuntu SMP Sat Oct 16 17:39:04 UTC 2010 i686 GNU/Linux

$LD_LIBRARY_PATH=`pwd` ./firefox
XPCOMGlueLoad error for file /home/user/firefox/libxpcom.so:
/home/user/firefox/libxul.so: undefined symbol: _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE
Couldn't load XPCOM.

====
./firefox
XPCOMGlueLoad error for file /home/user/firefox/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

    
    

    
  
I get the same issue with Fx 20.0.1, 64 bits, Linux version, downloaded from the FTP. I can't get Fx starting on my Debian Lenny.

    
    

    
  
(In reply to Folco from comment #79)
> I get the same issue with Fx 20.0.1, 64 bits, Linux version, downloaded from
> the FTP. I can't get Fx starting on my Debian Lenny.

Firefox 20.0.1 is Windows only. You should not be receiving updates on Linux to 20.0.1 nor should you manually install this build on anything but Windows. I recommend you roll back to Firefox 20.0 on Linux until we release Firefox 21.0 next week.

    
    

    
  
I got the 20.0.1 version here : http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/20.0.1/linux-x86_64/en-US/
So I though that I could use it on a Linux 64 bits.
Like you said, I tried with the 20.0 version : it fails with the same error. Here is a screenshot : http://www.mirari.fr/qNPq

I need to use Fx 17.0.5 ESR to get it working. It doesn't matter for me, but I can't use the latest version.

    
    

    
  
Mike Hommey, it seems like there are several comments since this was marked "fixed" who are having issues with releases (not ESR). Do we have a support article on this? I don't think it's very productive having these discussions on a "fixed" bug. If there is a bug here and it's not system config issue then we should get a new bug on file.

Mike, what do you think?
Flags: needinfo?(mh+mozilla)

    
    

    
  
Several different problems have unfortunately the same error message. The original cases are fixed. The latest one is that Debian Lenny is not supported. Version 18 and above (iirc) require a version of glib and gtk that are too new for it, as well as glibc (glib and glibs are confusingly two different things). The glibc requirement will probably go away with version 24, as a side-effect of the switch to gcc 4.7, but the glib/gtk one will remain.

Note Debian Lenny stopped receiving Debian security updates in february 2012, people shouldn't be using it to access the web.
Flags: needinfo?(mh+mozilla)

    
    

    
  
Thanks Mike. Do we have support documentation somewhere indicating as much? I think it would it would be worth documenting this so that users don't come to this bug report thinking this bug isn't fixed.

    
    

    
  
@Mike, Anthony,

There are people running older distributions under controled conditions, doing their own security updates. It shouldn't be Mozilla worrying about what OS people should or "shouldn't be using" to access the web. Under that line of thought, should people run Windows XP?

What happens here is Firefox failing to work on 3-4 year old Linux operating systems. 

According the http://www.mozilla.org/en-US/firefox/20.0/system-requirements/ Windows XP SP2 is supported. SP2 is from 2006?

I'm wondering why the system requirements are upped in such a way that it becomes a problem to run Firefox on Linux but are still conservative enough to have it running on older Windowzes.

    
    

    
  
There are a lot of factors that go into a decision to stop supporting a particular operating system or architecture. Not least of which is our ability to maintain a minimum viable product on aging technology and the number of users potentially affected by a de-support.

That said, Bugzilla is not a forum to discuss support decisions. Please direct your discussion to one of our mailing lists.

    
    

    
  
Sometimes factors are factors, other times factors are mere circumstances (ex: developer X upgraded build env to latest and greatest). I'm not saying this is the case, here. As a QA person, you probably know how that works, and how upgrading requirements for slightly newer minor versions sometimes - not always - causes problems, often without benefits. 

I'm not taking this discussion anywhere else since I still remember what happened with the sys requirements in 2008, that caused horrible problems for many Linux users, and how it was regarded as reasonable by Mozilla :-) If it's great for the majority, so let it be.

But if system requirements were validated at runtime, at least there would be less bugzilla noise around Firefox not working in system X, Y or Z.

    
    

    
  
(In reply to Gustavo Homem from comment #87)
> I'm not taking this discussion anywhere else 

That's your choice but I respectfully ask that you stop discussing it here.

    
    

    
  
(In reply to pvelkovski from comment #25)
> Try downloading Firefox manually from ftp://ftp.mozilla.org/pub, and make
> sure to choose the 64 bit version.


pvelkovski nailed it for me.  I'm on CentOS 6 installing FF 21.0 and Thunderbird 17.0.6.

    
    

    
  
I installed the libdbus-glib-1-2 package for firefox 24.0a1 on debian.
after that the problem showed for the XPCOM libxul.so error was gone and ff started fine.

    
    

    
  
(In reply to marco-ontour from comment #90)
> I installed the libdbus-glib-1-2 package for firefox 24.0a1 on debian.
> after that the problem showed for the XPCOM libxul.so error was gone and ff
> started fine.

Same solution here.

    
    

    
  
(In reply to zilmar.jr from comment #91)
> (In reply to marco-ontour from comment #90)
> > I installed the libdbus-glib-1-2 package for firefox 24.0a1 on debian.
> > after that the problem showed for the XPCOM libxul.so error was gone and ff
> > started fine.
> 
> Same solution here.

BUT, the problem persists while trying to run Thunderbird

    
    

    
  
I'm seeing this problem with Firefox29b3 on latest Ubuntu:

XPCOMGlueLoad error for file /home/luke/.local/share/Trash/files/firefox/libxul.so:
libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

    
    

    
  
I confirm that this bug persists on RHEL 6. I am seeing the "libdbus-glib-1.so.2: cannot open shared object file: No such file or directory" error with Firefox 29b06 (latest beta as of today).

    
    

    
  
(In reply to lorenzo.decarli from comment #94)
> I confirm that this bug persists on RHEL 6. I am seeing the
> "libdbus-glib-1.so.2: cannot open shared object file: No such file or
> directory" error with Firefox 29b06 (latest beta as of today).

The bug in Firefox that was causing this error was fixed a long time ago. It's possible that you're seeing this error because of an unsupported version of libdbus-glib or if you're using the incorrect Firefox build for your architecture.

If you want support on resolving this issue on your system I recommend contacting either your distribution's support channel or support.mozilla.org.

If you think there's a bug in Firefox then please file a new report.

    
    

    
  
I am not sure this bug has been fixed, since there appear to be a few bug reports similar to mine. It is worth noting that I downloaded Firefox from mozilla.org/beta, so this is not an issue with my distributor, and Firefox 28 works perfectly on the same platform (RHEL 6.5 64-bit).

It may also be that my platform (RHEL 6.5 64-bit) is not supported anymore. If so, could you clarify?

    
    

    
  
(In reply to lorenzo.decarli from comment #96)
> It may also be that my platform (RHEL 6.5 64-bit) is not supported anymore.
> If so, could you clarify?

We don't support specific distributions, instead we support different platform configurations (kernel, libraries, etc). You can check here to make sure your system meets those requirements as configured:

http://www.mozilla.org/en-US/firefox/28.0/system-requirements/

If you think your system meets those requirements as configured then please report an issue to support.mozilla.org. If they are unable to troubleshoot you to a resolution then there may indeed be a Firefox bug, in which case you should file a new bug report.

As I said before, there is nothing more to be done in *this* bug report.

    
    

    
  
lorenzo.decarli I've hit this bug once on Ubuntu 12.04 (and hadn't bothered to unsubscrive from the bug), only to realise that from all the existing web sites in the known universe delivering compiled software for linux, it is the mozilla.org that fails to recognise the proper version of Firefox required to download - 32bit vs. 64bit. It isn't helpful either that the download you get isn't explicitly named with "64bit" string. I mean, look at this two links:

https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/29.0b6/linux-i686/en-US/
https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/29.0b6/linux-x86_64/en-US/
Identical names, for the 32bit and the 64bit build. Now you go figure which one mozilla.org handed to you.

So try downloading directly from the ftp site and see if that works. And report back the result.

    
    

    
  
pvelkoski, you are right, I was trying to run the wrong version. The 64-bit works without issues. Sorry for the confusion!

    
    

    
  
(In reply to lorenzo.decarli from comment #99)
> pvelkoski, you are right, I was trying to run the wrong version. The 64-bit
> works without issues. Sorry for the confusion!

lorenzo.decarli you are not the one that should apologise for this confusion.

I warned about the problem that obviously exsists with the way mozilla.org chooses the appropriate version to be offered when you are trying to download firefox, or probably any other mozilla product, and the problematic file naming convention used for the binary packages a year and a half ago (comment #25 from 2012-09-12), but I guess they'll pretend that it's not a huge problem until someone files an official bug report.

I would have done it myself, but I have no idea where specificaly I should do it, as the categories offerted on this page https://bugzilla.mozilla.org/enter_bug.cgi  are not really related to the aforementioned problems. So for the love of god, let someone following this bug, that is more informed about the ways are being run here (mozilla) do something about it!

Anthony Hughes, since your last post started with "We ...", and there is a title next to your name (QA Mentor; does the QA stand for "Question and Answer" or "Quality Assurance"?! )I'm looking at you!

    
    

    
  
(In reply to pvelkovski from comment #100)
> Anthony Hughes, since your last post started with "We ...", and there is a
> title next to your name (QA Mentor; does the QA stand for "Question and
> Answer" or "Quality Assurance"?! )I'm looking at you!

QA means "Quality Assurance".
Q&A means "Question and Answer".

I hope that clears up any confusion.

    
    

    
  
> QA means "Quality Assurance".
> Q&A means "Question and Answer".
> 
> I hope that clears up any confusion.

Anthony Hughes, I asked for assistance in reporting the problems mentioned in my previous post, but instead of that you just cleared the meaning of your title. The thing is I don't speak the "management language", and I can only speculate about the submeaning of your comment. Were you trying to say - "that kind of assistance is not in my job description, so I don't intend to do anything about it"?!

There are two related problems here resulting in people getting the wrong version of firefox which results in them thinking that there is a software bug in it. Any suggestion about the proper place/way/method to report those problems?

    
    

    
  
TL;DR
If you are still experiencing this issue and need help resolving it then please post a question to support.mozilla.org. If you think there is a Firefox bug here then please file a NEW bug report to bugzilla.mozilla.org. If you are having problems with a build provided by your Linux distribution then please contact your distribution's support channel. 

(In reply to pvelkovski from comment #102)
> Were you trying to say "that kind of assistance is not in my job description, so I don't intend
> to do anything about it"?!

My job description is largely irrelevant. I feel it's my duty to direct people to the best place to get the help they need. Reporting issues to a closed bug in bugzilla, especially one closed so long ago, is probably the worst way to do that. That is why I suggest going to support.mozilla.org, or the respective distribution's support channel, if that seems appropriate. I would be doing you a disservice to suggest otherwise or to ignore cries for help altogether.

> There are two related problems here resulting in people getting the wrong
> version of firefox which results in them thinking that there is a software
> bug in it. Any suggestion about the proper place/way/method to report those
> problems?

I usually point users to firefox.com, beta.mozilla.org, aurora.mozilla.org, or nightly.mozilla.org depending on which branch they want to download. That said, I personally always download my builds from ftp.mozilla.org.

These websites should be serving you the correct build for your platform. If they are not then I recommend filing a bug against the website. You can do so here: https://bugzilla.mozilla.org/enter_bug.cgi?product=www.mozilla.org

If you are a user on a Linux distribution which provides its own Firefox packages then I usually recommend you stick to those packages. Unless of course you want to go outside of their supported builds which I then recommend the same websites mentioned earlier. Any issues with builds received from your distribution's package manager should be reported to your distribution's bug tracker or support channels. We can only provide support for the bits we distribute ourselves.

If you are in an enterprise then you should be contacting your IT department as front-line support. If that process yields a Firefox bug then I expect them to do their due diligence and report it to us here.

Going back to your original concern about "submeaning". What I post in bugzilla is really quite literal. If you are reading a submeaning in my words then I apologize for poorly choosing my words, but there is really no intention of submeaning there. 

All of that said, this is precisely the kind of conversation we should be having elsewhere. If you want help troubleshooting an issue with one of Mozilla's products/services, report it to support.mozilla.org. If you want to report a bug in one of Mozilla's products/services, report it to bugzilla.mozilla.org in a NEW bug report. 

I'll be happy to help you troubleshoot this further on support.mozilla.org, as would our highly qualified support team. I'll also be happy to entertain investigation of a bug on bugzilla.mozilla.org but I will require a NEW bug report to be filed. 

Thank you.

    
    

    
  
I believe there is a genuine bug issue here relating to 32 bit Mozilla downloads being offered to those on a 64 bit distro wishing to for whatever reason download and install a Mozilla  build of Firefox.

Should someone open a bug to that effect, or discover one that is already open  perhaps they will note that in a comment here.

Regarding support.mozilla please note 
>There is currently an open question relating to this. 
Can the webmaster fix mozilla's web site so that users don't end up with non working 32bit version of firefox on their 64 bit Linux (see bug #723487)? 
https://support.mozilla.org/en-US/questions/994466
>The related support.mozilla.org documentation on installing Firefox is here
https://support.mozilla.org/en-US/kb/install-firefox-linux

To my mind the current behaviour should be improved. At the very least a 64bit user should receive some warning that the 32bit download may not be suitable. Failing that maybe support.mozilla.org documentation may be improved to cover this point.

Clearly this is the wrong bug or wrong place for discussion of this. I am posting to provide a link to an open and relevant discussion.

    
    

    
  
Agreed. For future reference, I think discussion regarding this issue should move from this bug report and continue on:

https://support.mozilla.org/en-US/questions/994466

and possibly on:

https://support.mozilla.org/en-US/kb/install-firefox-linux/discuss/2473

    
    

    
  
Anthony Hughes thank you for, this time, the extremely helpful answer. I'm wondering why I was forced to "use pliers to pull out the words out of your mouth (figuratively speaking, it's an expression used in my country) in order to receive the information and assistance I asked for in more than one comment, but I confess I'm not someone who gives up easily and I have no problems of being anoying (and rude) when I'm involved into something I find important.

Anyway, I've finally opened a bug report concerning Mozilla's website - it's bug #995539.

    
    

    
  
(In reply to Syed M Shaaf from comment #39)
> Okay I can confirm. 
> 
> 1. First I downloaded the thunderbird from the main site, by clicking
> download. And it didnt work with the error
> libasound.so: cannot open shared object file: No such file or directory
> 
> Then I downloaded from the ftp site, like mentioned below. And it works now.
> ftp://ftp.mozilla.org/pub/thunderbird/releases/latest/linux-x86_64/en-GB/

Yes that worked for me installing 31.1.1 from FTP - normal download obviously doesn't recognise 64 bit OS

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: