Closed Bug 233815 Opened 20 years ago Closed 18 years ago

Release i586-compatible builds for Linux

Categories

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

x86
Linux
enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: sven_leo, Unassigned)

References

Details

(Whiteboard: wfm-gtk2)

Attachments

(1 file)

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

Created:
Updated:
Size: