Closed Bug 233815 Opened 22 years ago Closed 19 years ago

Release i586-compatible builds for Linux

Categories

(Firefox Build System :: General, enhancement, P3)

Product:
Firefox Build System
Component:
General
Platform:
x86
Linux
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: sven_leo, Unassigned)

References

Details

(Whiteboard: wfm-gtk2)

Attachments

(1 file)

Screenshot of Firefox running on an i586 Linux system
99.83 KB, image/png
Details
User-Agent: Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 The script run-mozilla.sh returns an Error in Line 453. It can not start firefox-bin. I suspect the the reason is that Processors before i686 are no longer supported. If that is the case I want to complain about that because nice fast browsers need to run on older machines. I am unable to build firefox myself because of the complexity of the build environemt. It works on a P3. Reproducible: Always Steps to Reproduce: 1.Install firefox 2.run ./firefox 3.
*** Bug 233858 has been marked as a duplicate of this bug. ***
Bug 79668 (old Seamonkey nightly) was similar. Prog.
The very same problem was also reported in Bug 211138 and Bug 210360. Oddly enough, In both cases it seemed to have vanished later on. Prog.
Same problem exists on my Dell Latitude CP laptop, using the official 0.8 linux 686 build. Looks to me as if the default built may have been made for an architecture which is more restrictive than what is documented under "System Requirements"? dplatt@plattop:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 5 model : 8 model name : Mobile Pentium MMX stepping : 1 cpu MHz : 233.867 fdiv_bug : no hlt_bug : no f00f_bug : yes coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 mmx bogomips : 466.94
I see this too on an old Intel Pentium (running Red Hat Linux 7.2) when trying to start Firefox 0.8 for Linux. run-mozilla.sh: line 72: 1604 Illegal instruction "$prog" ${1+"$@"}
Status: UNCONFIRMED → NEW
Ever confirmed: true
I am also getting this getting the same bug with AMD K6 3D running Fedora 2.4.22-1.2166.nptl kernel. I have tested with the Feb. 17, 2004 nightly build with the same results of: > /usr/local/firefox/firefox /usr/local/firefox/run-mozilla.sh: line 451: 19595 Illegal instruction "$prog" ${1+"$@"} When running the firefox-bin I get: > /usr/local/firefox-bin Illegal instruction To get this far I had to add /usr/local/firefox to my LD_LIBRARY_PATH variable.
I've never run FF on any platform before today. On my Fedora Core 1 K6/3-550 machine I untarred today's ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-i686-linux-gtk2+xft.tar.gz into /usr/local/firefox. I created a new user firefox, /home/firefox/.firefox, /home/firefox/.firefox/default, & /home/firefox/.firefox/default/prefs.js. Then I ran /usr/local/firefox/firefox -createprofile "default /home/firefox/.firefox". NAICT, for purposes of this bug, WFM.
Whiteboard: wfm-gtk2
I have same problem with AMD-K6(tm) 3D processor /usr/lib/firefox/run-mozilla.sh: line 72: 3030 Illegal instruction "$prog" ${1+"$@"} and gdb bt gives: #0 0x4013baa3 in operator new(unsigned) () from /usr/lib/firefox/libxpcom.so #1 0xbffffad4 in ?? () #2 0x4013bb31 in operator new[](unsigned) () from /usr/lib/firefox/libxpcom.so #3 0x08bc075c in RgnRectMemoryAllocator::RgnRectMemoryAllocator(unsigned) () #4 0x08bc32ce in nsRegion::MoveBy(int, int) () #5 0x08bc331d in nsRegion::MoveBy(int, int) () #6 0x08be5ae5 in operator new(unsigned, std::nothrow_t const&) () #7 0x084b59c2 in _init () #8 0x405fa121 in __libc_start_main () from /lib/libc.so.6
I suggest to adjust the build system a little that it is guranteed that no newer x86 extensions are being used unless wrapped by special code and an alternative path (like done for the iDCT stuff in the JPEG/JFIF code).
Flags: blocking0.9?
not a blocker for 0.9, it'd be nice to have a fix if someone wants to do the legwork though.
Flags: blocking0.9? → blocking0.9-
QA Contact: mconnor
the sumary should be changed as this isnt afecting only the K6-3 the K6-2, K6, pentiums, i586 likes, 486 and other below i686 are also afected... this summary makes this bug look like a small issue that isnt... i dont agree that this isnt a bloc ker, as people with low end PCs, that are the ones that might want to use firefox, cant use it because it only works in moderm CPUs so we have to chose between firefox 0.7, the full mozilla, konqueror and the lights ones (dillo, links, lynx) firefox will lose in this equation
Changing summary. It is clear from comment 4 and comment 5 that this is not an AMD-only bug. Prog.
Flags: blocking1.0?
Summary: Firefox does not start on a K6-3 Processor → Firefox does not start on a certain processors (e.g. AMD K6-3, Intel P1 & P1-MMX)
is this something that building for a different target can fix? We can always see if there's a contrib build available. To be honest, the only case that really matters is the K6-2/3s, since the P1's are under the minimum system requirements. (And way under recommended specs) And to be frank, this is a small enough part of the market that its not really going to be a priority for anyone not affected (5+ year old PCs running Linux is a _really_ small marketshare).
The machine mentioned in comment 7 is actually running a K6-III+ 450. It also runs 0.8 booted to Win98. It's a shame one can run Firefox under win just fine on these older boxes, but not after wiping win and installing Linux. I tried with 0.8 unpacked to /usr/local './firefox -createprofile "firefox /home/moz/.firefox" on a machine with K6/2 400 running Mandrake 10 and got in line 451 the 'Illegal instruction "$prog" ${1+"$@"}' error seen by others here and in bug 211138 and bug 210360. Tweaking summary further. All the indicated processors are Socket 5/7 pre-Pentium II/Athlons, which is considered i586.
Summary: Firefox does not start on a certain processors (e.g. AMD K6-3, Intel P1 & P1-MMX) → Firefox does not start on all i586 processors (e.g. AMD K6-2 & K6-III, Intel P1 & P1-MMX)
On the machine in comment 7, I changed the CPU from K6-III to K6/2 just for testing this bug. gtk2-xft 0.8 seems to work the same with either CPU. The CPU is running with PC133 SDRAM @ 100 FSB X 5.5, SiS 530 chipset (Asus P5S-B).
I can confirm that the release Firefox 0.8 does not work on an old Pentium 100 laptop (a Toshiba Satelite 115CS maxed out at 40 Megs ram). You must recompile it i586 for it to work.
ok, so basically to "fix" this we need to release a version for i586 CPUs. That's probably the only viable option. moving to build-config,
Assignee: firefox → bryner
Severity: critical → enhancement
Component: General → build-config
QA Contact: mconnor → asa
Summary: Firefox does not start on all i586 processors (e.g. AMD K6-2 & K6-III, Intel P1 & P1-MMX) → Release i586-compatible builds for Linux
*** Bug 238681 has been marked as a duplicate of this bug. ***
*** Bug 242238 has been marked as a duplicate of this bug. ***
*** Bug 239765 has been marked as a duplicate of this bug. ***
Ok, I like to *think* I can follow BugZilla on a fairly complicated project. But the comment on my personal original bug with which it was closed out and moved here suggested strongly that there *was* a 586 build somewhere, so all I'd have to do would be go get it. And I don't see any links here at all to such a thing. Am I blind? On the "we don't need to" topic, I have one word: The Third World. IE: like hell you don't.
+ing to get on bryner's radar.
Flags: blocking1.0? → blocking1.0+
Yes, compiling for i586 would work. You may be able to tweak it so the builds compile for i586 but run fast for i686 (-mcpu/-march combo) but may be messy, and should be seperated for i586 and i686 builds.
Well there is definitely a problem with the binary downloaded from firefox official site (0.8). It works fine on machine but I have a few dell client machines where it dumps the "illegal instruction". I ended up downloading the source code from the CVS and re compiling it on my server and then making a distribution tarball and untarring it on my dell machines. The version is now 0.8+. Cheers Prash
I've run into this quite a lot in the past in various apps. The fix is pretty straightforward, of course: -march=i586 This can be mixed with -mcpu=NEWERCPU (a.k.a. -mtune) to only use <= i586 instructions but still otherwise optimize (in terms of alignment and instruction scheduling) for later architectures. In my 'day job's application I find that code with -march=i586 is not discernably slower than -march=i686 etc, but is more compatible. I combine it with a slightly more exciting -mcpu. I don't expect the difference between -march=i586 and -march=i686 to actually be measurable (while keeping -mcpu constant) -- at least from disassembling the output for my app, GCC's use of i686-specific instructions is rather rare (but devastating to non-i686 archs when they happen, of course).
Given the small-ish number of i586 machines out there, we should be releasing for i586 in addition to i686, not instead of i686. It makes no sense for the vast majority of users to take a perf hit so that the tiny number of i586 users can use Firefox. However, we can and should also provide i586 builds of releases so that i586 users can use Firefox. As for nightlies, maybe it would make sense to switch the default build configuration over to i586, so that everyone can use a single binary and there is less maintenance hassle. It's not of critical importance that nightlies are blazing fast, because that is not their main focus.
Let me please cast a vote in favor of Ali's suggestion. Is the release manager on the CC list, and can we finally mark this bug ASSIGNED, maybe?
I doubt the number of i586 users is as small as you think. Linux doesn't require the HP that XP does, so users of perfectly good 5-7 year old machines are not compelled to upgrade. The criteria for retiring old i586 boxes in many cases seems to be whether the BIOS supports >8GB HD when the old HD fails, so that a new one can be installed without futzing with Disk Mangler or a PCI add-in HD controller. I got my first >i586 box only 3 months ago. I have about 9 working 200-550 MHz i586 boxes with various flavors of seamonkey installed. They are how I work through cross-platform QA issues, while the P4 runs OS/2 24/7. I installed FF primarily for following this bug.
I don't thinks it's an issue of blazing-fast versus plodding turtle -- perhaps I wasn't being clear enough. I haven't measured it for Mozilla, but in our sizeable speed-critical app there just wasn't ANY measurable slowdown in using -march=i586 -mcpu=i686 versus -march=i686 -mcpu=i686. I'm suggesting that someone try a similar test with Mozilla before anyone even thinks of going through the bother of generating and distributing separate builds for i586 machines.
I'm for Ali's suggestion with the nightlies. I'm also for using -mcpu=i686 -march=i586 for releases. Slackware's compile of Mozilla 1.6 uses -march=i486 and there's no speed difference I can see on my Athlon XP.
My K6-III ran 0.8 & 0.9, but 0.9.1 gives: run-mozilla.sh: line 451: 2691 Segmentation fault "$prog" ${1+"$@"}
Ignore comment 31.
Loaded firefox 0.9.3 on 2.4.22-1.2199.nptl Fedora Core 1. Seems to run reasonably well. Some pages www.foxnews.com, sbc.login.yahoo.com, and www.cnn.com for examples appear to take a lot of CPU to load. It is possible that they are loading more complex pages than they used to.
On Mandrake 10.1 with libstdc++5 installed on K6/2-400 ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/0.10/firefox-1.0PR-i686-linux-gtk2+xft.tar.gz seems to start and run just fine.
on slackware 10, in a 486, firebird 0.10 also started fine, when in the past 0.8 or 0.9 (cant recall) couldnt start if something was made to try to fix this bug, i think that we could close it, but if this was just luck, this bug should stay open and a fix should be made to make sure that all mozilla packages work at least on the minimum recomended hardware (i586, i586 with mmx?)
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
*** Bug 267167 has been marked as a duplicate of this bug. ***
The current version of Firefox does run on i586, although it's labeled as being i686-only. I am posting this comment using Firefox on my i586 machine. It never crashed nor did anything weird on account of my machine being i586. My complete system specs are: AMD K6-2/500 MHz processor on FIC VA-503+ motherboard, 144 MB RAM, Sound Blaster 16 sound card, Trident 3DImàge 9750 AGP video card with 4 MB RAM, Seagate 8.4 GB hard drive, CD-ROM drive/recorder, network adapter/ADSL modem, running Linux kernel 2.4.25-klg (i586), Kurumin 3.1 distro (Debian-based).
Little something to add to my last comment, I've used older versions of the software (namely Mozilla Firebird 0.7, comes pre-installed in a previous release of this distro, and Firefox 0.8, which comes pre-installed on this distro I'm using) on this same i586 machine without any problems whatsoever.
Yet another something to add, that I later found might be relevant: I downloaded this Firefox 1.0 I'm using from the official website, and the contents of the "about:buildconfig" page have something interesting... here they are: about:buildconfig Build platform target i686-pc-linux-gnu Build tools Compiler Version Compiler flags gcc gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -pthread -pipe c++ gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe -I/usr/X11R6/include Configure arguments --disable-ldap --disable-mailnews --enable-extensions=cookie,xml-rpc,xmlextras,pref,transformiix,universalchardet,webservices,inspector,gnomevfs,negotiateauth --enable-crypto --disable-composer --enable-single-profile --disable-profilesharing --disable-debug '--enable-optimize=-Os -freorder-blocks -fno-reorder-functions -gstabs+' --disable-tests --enable-official-branding --enable-default-toolkit=gtk2 --enable-xft --disable-freetype2 --enable-static --disable-shared Also, for completeness' sake, here's the contents of my /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping : 12 cpu MHz : 503.707 cache size : 64 KB fdiv_bug : no hlt_bug : yes f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr bogomips : 1005.97 Even though the compile target is set to "i686-pc-linux-gnu", it does run and is running on an i586 machine without having any problems... Question: Would a build with this same configuration run on older i586's (especially Pentium classic/MMX, AMD K5 and Cyrix)?
yes, i already run firefox 1.0 in a 486 (slowly but worked) the diference in i586 compile and i686 compile is just a few instruction that are rarely used and if in firefox 0.7 and 0.8 it was used somehere, right now it seens that isnt being used any more (luck? workaround?) distro builts might had already patch or work around for this problem... i think that in every release should be tested in a machine below i686 and see if it works, if it fails, a i586 build should be released (or with a workaround)
Keep in mind when you're talking about what we "should" do that our posted minimum specs are Pentium II-233 or higher, so Pentium "classic" really isn't a concern. So we're left with AMD-K6/Cyrix processors running Linux GUI desktops. That's a really small number and will do nothing but decrease. I couldn't justify dedicating any testing resources towards that type of thing, let alone spinning a dedicated build and putting QA into it. I'm not advocating directly breaking things, but eventually we have to reach a point where we drop things we're not going to support. Think GTK1.2, or MacOS 9. Supporting ancient stuff at the price of taking resources away from integrating with current/future platforms is a bad tradeoff.
i'm not asking to support 486 and pentium classic, but K6 and Cyrix are i586 cpus and are still very common like you, several people here think that old machines are rare and will decrease, but they forgot that the world isnt just the EUA and (western) europe, in MANY countries a K6-2@400 is a very good machine and even that is expensive these people forget that in some countries, buying a new computer one need to spend several complete monthly salary more modern lower grade CPUs like VIA, winchip and other may (or may not, i dont really know) be a i586 cpu if these companies build and _sell_ this CPUs, there is market for then, and you bet that isnt in the EUA, canada and western europe and i'm not even talking about laptops and schools and libraries we are not asking the moon, its a well known fact that there is no real speed difference between i586 and i686 (and that can show easily how so little i686 builts broke in i586 CPUs), we ask for the mozilla team to build i586 binaries (paralel with i686 build if people really want them) there is little resource needs for this, QA is the is the same, only really HD space is the true resource that can be wasted to save it, we could only do the i586 builds when they are needed, if there is a report that the i686 build isnt working on i586 cpus, mozilla team would run the i586 build script and generate i586 only when needed this way all i586 people could use the program and this would be fixed without much trouble none of the people here wants to slow down mozilla, but i think that too many people forget that their country isnt just like the rest of the world, i586 cpus arent that old nor weak and so SHOULD be supported, not ignored
A side note: I've moved to using Gentoo on amd64 since my last comment. Some added comments relating to processors: Only one of VIA's EPIA processor chips (the Eden C3/Ezra) are considered (in Gentoo's eyes) i586 (no cmov instruction, basically a AMD K6-3 or a P2 with 3DNow support). The Nehemiah (C5XL)/C5P and Esther C5J (Via C7/Epia Nano) processors are i686. Info gathered at http://gentoo-wiki.com/Safe_CFLAGS
Assignee: bryner → nobody
QA Contact: asa → build.config
Version: unspecified → Trunk
We're not going to change our build-config now and we don't have the resources or interest to produce a second set of linux builds, so WONTFIX. (Workaround: compile yourself)
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
You haven't tried to compile said build on a i586 system, haven't you? It's ssssssssssssslllllllllllllllllloooooooooooooooooooooooowwwwwwwwwwwww.
You don't need to compile _on_ the i586 system, you just need to mod the build-config to make those builds.
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: