Status

()

The Mozilla Toolkit is a set of APIs, built on top of Gecko, which provide advanced services to XUL applications. These services include Profile Management, Chrome Registration, Browsing History, Extension and Theme Management, Application Update Service, and Safe Mode. (More info)

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.

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

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?

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.

(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 ' ? '

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

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

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?

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.

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.

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

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.

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

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

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

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.

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

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.

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

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?

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.

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

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

(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 herehttps://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.

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

CC: jimc

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