4 ms·

Was Firefox for Linux x64?

en4bz 12y ago
Seems to be 64 bit on Ubuntu 14.10 $ readelf -h /usr/lib/firefox/firefox ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Micro Devices X86-64
- Thaxll 12y ago
  Or just use file: file /usr/lib/firefox/firefox /usr/lib/firefox/firefox: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=16336605009f841acd45261f5f904be8509cfe21, stripped
shmerl 12y ago
I use it for years on Linux already. I didn't even know on Windows Firefox wasn't 64 bit yet.
cesarb 12y ago
Firefox has been available both as 32-bit and 64-bit on Linux for a long time. Quoting myself (https://news.ycombinator.com/item?id=8629233 https://news.ycombinator.com/item?id=8629233): ---- From what I have read, for software which wasn't originally developed for Windows, especially if the code base is old enough, porting to 64-bit is harder on Windows than on other systems. The problem is that, while the Unix-based world went the LP64 way (int is 32-bit, long and pointers are 64-bit), Windows went the LLP64 way (int and long are 32-bit, pointers are 64-bit). A lot of Unix programmers tended to behave as if "long" was the largest native type ("long long" on 32-bit uses a pair of registers). They have to scrub their whole code base for things like assuming an object's size or array index will always fit on a "long". ---- For Firefox, there's the additional problem of plugins. For a long time, plugins on Windows have been 32-bit, and also for a long time, plugins for Firefox on Windows (and other operating systems) were in-process, so it wasn't possible to use a 32-bit plugin with a 64-bit browser. Nowadays, not only can Firefox use a separate process for plugins, but also the whole idea of browser plugins seems to be dying, so it's less of a problem.
- jheriko 12y ago
  the whole LP64 vs LLP64 'issue' is a massive red herring. even in the most despicable code bases this is relatively quick and easy to 'fix', its just one of those things that on the face of it looks like a lot of work, and is genuinely a brainless chore of find and replace with care. its worth doing right anyway for plenty of reasons beyond portability, like readability and maintainability. using long on its own imo is a code smell. except for android (and maybe linux, i can't remember otoh) long long is 64-bit and int is 32. but more generally you can macro it away or use some standard size type header and do the replacements to fix it. the real problems i've seen with 64-bit portability are from bad serialisation code, where struct padding breaks things, and hacks that rely on pointer casts to ints etc. those are less easy because you can't find/replace them and so it requires thought, not just care, to remove those issues safely.
- dblohm7 12y ago
  The JIT needed some fixing to work correctly with SEH on Win64.

en4bz 12y ago

Seems to be 64 bit on Ubuntu 14.10 $ readelf -h /usr/lib/firefox/firefox ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Micro Devices X86-64

Thaxll 12y ago
Or just use file: file /usr/lib/firefox/firefox /usr/lib/firefox/firefox: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=16336605009f841acd45261f5f904be8509cfe21, stripped

shmerl 12y ago

I use it for years on Linux already. I didn't even know on Windows Firefox wasn't 64 bit yet.

cesarb 12y ago

Firefox has been available both as 32-bit and 64-bit on Linux for a long time. Quoting myself (https://news.ycombinator.com/item?id=8629233 https://news.ycombinator.com/item?id=8629233): ---- From what I have read, for software which wasn't originally developed for Windows, especially if the code base is old enough, porting to 64-bit is harder on Windows than on other systems. The problem is that, while the Unix-based world went the LP64 way (int is 32-bit, long and pointers are 64-bit), Windows went the LLP64 way (int and long are 32-bit, pointers are 64-bit). A lot of Unix programmers tended to behave as if "long" was the largest native type ("long long" on 32-bit uses a pair of registers). They have to scrub their whole code base for things like assuming an object's size or array index will always fit on a "long". ---- For Firefox, there's the additional problem of plugins. For a long time, plugins on Windows have been 32-bit, and also for a long time, plugins for Firefox on Windows (and other operating systems) were in-process, so it wasn't possible to use a 32-bit plugin with a 64-bit browser. Nowadays, not only can Firefox use a separate process for plugins, but also the whole idea of browser plugins seems to be dying, so it's less of a problem.

jheriko 12y ago
the whole LP64 vs LLP64 'issue' is a massive red herring. even in the most despicable code bases this is relatively quick and easy to 'fix', its just one of those things that on the face of it looks like a lot of work, and is genuinely a brainless chore of find and replace with care. its worth doing right anyway for plenty of reasons beyond portability, like readability and maintainability. using long on its own imo is a code smell. except for android (and maybe linux, i can't remember otoh) long long is 64-bit and int is 32. but more generally you can macro it away or use some standard size type header and do the replacements to fix it. the real problems i've seen with 64-bit portability are from bad serialisation code, where struct padding breaks things, and hacks that rely on pointer casts to ints etc. those are less easy because you can't find/replace them and so it requires thought, not just care, to remove those issues safely.
dblohm7 12y ago
The JIT needed some fixing to work correctly with SEH on Win64.