Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#10542 closed Bug Report - General (Upstream Bug)

configure incorrectly detects VIA c3 and enables cmov etc...

Reported by: andrew@… Owned by:
Priority: minor Milestone:
Component: Packaging Version: 0.24.2
Severity: medium Keywords: c3 cmov configure
Cc: Ticket locked: no


On gentoo using the media-tv/mythtv-0.24.2_p20120315 ebuild ./configure uses --enable-proc-opt which incorrectly assumes that my Ezra CPU has cmov extensions etc... When it has compiled the binary crashes with 'illegal instruction' trying to run mythtv-setup

Attempting to work around this by passing --tune=c3 --arch=i586 --enable-mmx --enable-amd3dnow --enable-memalign-hack --disable-sse --disable-ssse3 --disable-amd3dnowext --cpu=c3 etc....

Seems this bug appeared 5 years ago and was squashed - but it seems to have come back.

Attachments (6)

Text File (3.4 KB) - added by andrew@… 10 years ago.
./configure output
configure_output.txt (1.7 KB) - added by andrew@… 10 years ago.
./configure --enable-proc-opt 2>&1 | tee $HOME/configure_output.txt
cpuinfo.txt (402 bytes) - added by andrew@… 10 years ago.
VIA Ezra CPU info
config.ep (155.6 KB) - added by andrew@… 10 years ago.
c3-configure (3.9 KB) - added by andrew@… 10 years ago.
part of .configure output run on the c3 once the patch was applied to gcc
find-cmov (173 bytes) - added by andrew@… 10 years ago.
script to find files containing cmov instructions below the current directory

Download all attachments as: .zip

Change History (18)

Changed 10 years ago by andrew@…

Attachment: Text File added

./configure output

comment:1 Changed 10 years ago by Raymond Wagner

Component: MythTV - GeneralPackaging
Resolution: Won't Fix
Status: newclosed

I'm closing this one Won't Fix. 0.25 is due for release in under a week, after which I intend to drop the 0.24 ebuilds from our repository. All support for XvMC playback has been removed from 0.25, effectively ending the old 586-class C3 as a viable platform for MythTV.

comment:2 Changed 10 years ago by Simon Kenyon <simon@…>

will this make it unusable as a slave backend?

this was what i was just in the process of setting up.

comment:3 Changed 10 years ago by danielk

Simon, it will still work as a backend. If you can come up with a simple patch for configure, we'll apply it.

Changed 10 years ago by andrew@…

Attachment: configure_output.txt added

./configure --enable-proc-opt 2>&1 | tee $HOME/configure_output.txt

Changed 10 years ago by andrew@…

Attachment: cpuinfo.txt added

VIA Ezra CPU info

Changed 10 years ago by andrew@…

Attachment: config.ep added


comment:4 Changed 10 years ago by andrew@…

A slave backend is what I'm setting up as well - the 250 watts my P4 backend was pulling made the cupboard rather hot and caused the Mrs to turn it off - not too good for what should be an always on box. - 67 watts under full load with the c3 looks more likely to survive the heat police, and it's quieter :-)

comment:5 Changed 10 years ago by andrew@…

Master backend is what I meant - not that it makes much difference.

comment:6 Changed 10 years ago by sphery

Milestone: 0.24.3
Resolution: Won't Fix
Status: closednew

comment:7 Changed 10 years ago by sphery

Resolution: Upstream Bug
Status: newclosed

Re-closing as an upstream bug.

As mentioned in , the problem is that the compiler and underlying system thinks it's a Pentium-2-based system (where Pentium 2 supports cmov). Since configure asks the compiler for proper native configuration information, we end up getting incorrect information and building for the wrong arch. Workarounds are described in the linked post, but the proper solution is to fix the underlying compiler/system.

comment:8 Changed 10 years ago by Simon Kenyon <simon@…>

the problem "might" be because the OP has not rebuilt gcc with their new CFLAGS since installing the system. or maybe they did not change the CFLAGS after installing the system.

one solution would be to assume that the CFLAGS, etc in /etc/make.conf are correct and not call "strip-flags" in the ebuild.

comment:9 Changed 10 years ago by andrew@…

This explains why searching for cmov instructions on my machine returns so many positives even with i586-pc-linux-gnu as CHOST!

I have now rebuilt gcc (emerge -1av gcc) on the c3 machine (previous compile was done in an NFS exported CHROOT on my core2 :-), two days later it still thinks that -march=native == -march=pentium2 even though gcc configure includes --with-arch=i586. 4.6.2 and 4.4.4 ebuilds (chroot compiled) both have the problem. 3.4.6 (gcc of a c3-ish vintage) doesn't support -march=native and probably won't compile most of the rest of gentoo anyway...

Anyhow currently have the backend up and running by <ctrl-c>-ing emerge mythtv after configure had finished, re-running configure manually (after adding the correct options for my c3 to the standard configure command) then running "ebuild /path/to/mythtv.ebuild compile" followed by "ebuild /path/to/mythtv.ebuild qmerge"

Thanks for the help chaps! - Will post a reference to the upstream bug / and or a work-around if I find one. (Once I work out if it's a gcc or a gentoo specific issue that is :-).

(Who ignored that good advice in the wiki not to try running mythtv on gentoo or old hardware....)

comment:10 Changed 10 years ago by andrew@…

Right here's what I found out:

1) -march=native is broken for the c3 in all versions of gcc from gcc-4.4.4 to gcc-4.6.2 and probably current (see which includes a patch to enable the correct flags for my processor.

2) after applying this patch to GCC and re-installing it, mythtv ./configure --enable-proc-opt on the c3 box disables cmov but still gets some of the options wrong (see attached) you get:
CPU: x86 x86_32 (VIA Ezra), MMX=yes, MMX2=yes, 3DNow!=yes, 3DNow! extended=yes, SSE=yes, SSSE3=yes, CMOV=no.
Should be:
mmx=yes, mmx2=no, amd3dnow=yes, amd3dnowext=no, sse=no, SSE3=yes, cmov=n

ffmpeg ./configure seems to have a similar problem by the way - if this is what you are using as a template.

3) if you pass the -ffast-math option to gcc versions gcc-4.4.4 to gcc-4.6.2 (and probably current) when used as a linker it adds cmovne instructions into the linked code even if -march=c3 is set. (gcc-3.4.6 doesn't do this) - this explains most of the cmov instructions I found in my gentoo i586-pc-linux-gnu with -march=c3 CFLAGS system (also appear in my -march=k6-3 laptop buy the way) - that and the icedtea-bin files which isn't that surprising really - I'm still trying to wheedle out the rest and pluck up the courage to file a gcc bug...

4) I spent ages trying to work out where /mythtv/external/FFmpeg/libavformat/ was getting cmov instructions from then discovered it has the function name '<mov_read_cmov>' in it which was giving me a false positive - doh! (see my find cmov script, again shamelessly stolen from someone else attached)

I have found that the rest of gentoo's ebuilds don't seem to mind being merged in a chroot using my core2 - even ffmpeg - they continue to honor my -march=c3 CFLAGS in make.conf. For this reason (and as compiling on the C3 itself even with distcc just takes forever) I would suggest that :
a) mythtv's ebuilds be updated to honour any -march CFLAGS in make.conf (as suggested by Simon Kenyon above) - by all means continue to strip -Ox and other stuff out
b) the ./configure script be updated to set the correct options for VIA processors (see the patch in as a starting point which seems sensible and works for me - anyone out there got a cyrix to fill in the 'fixme'?)

I did have a go at creating a new ebuild so I could test a configure patch myself but the GIT overlay magic got me royally confused when it started downloading another version of mythtv using my new ebuild's name (I've got a serious learning curve by the looks of things!). If someone could point me to the right part of the configure files and explain what's happening with the ebuild I would be happy to give it another try though.

Changed 10 years ago by andrew@…

Attachment: c3-configure added

part of .configure output run on the c3 once the patch was applied to gcc

Changed 10 years ago by andrew@…

Attachment: find-cmov added

script to find files containing cmov instructions below the current directory

comment:11 Changed 10 years ago by Simon Kenyon <simon@…>

for what it is worth i just rebuilt my epia machine to use as a slave backend. i downloaded an minimal iso, installed the base system and updated /etc/make.conf i did and emerge world and then i installed enough so that i could emerge git head mythtv (hacking the ebuild to not strip-flags) the result is a working mythbackend.

i have not had to do anything special to gcc so i am not sure why you are having such problems.

comment:12 Changed 10 years ago by andrew@…

You're right Simon. I've also now commented out the following lines in my e-build and it works fine, even cross-compiling on the core2 :-). By making the ebuild use -march=c3 (from make.conf) rather than letting it assume -march=native, the gcc bug never comes into play.

#filter-flags "-march=*" "-mtune=*" "-mcpu=*"
#filter-flags "-O" "-O?"



I also haven't had any obvious problems with sse and friends being set to yes (including using the box for commflagging). I guess it must auto-detect cpu capabilities at runtime.

Note: See TracTickets for help on using tickets.