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

[andrew@…]

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.

[andrew@…]

./configure output

[Raymond Wagner]

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.

[Simon Kenyon <simon@…>]

will this make it unusable as a slave backend?

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

[danielk]

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

[andrew@…]

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

[andrew@…]

VIA Ezra CPU info

[andrew@…]

config.ep

[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 :-)

[andrew@…]

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

[sphery]

Re-closing as an upstream bug.

As mentioned in http://www.mythtv.org/pipermail/mythtv-dev/2012-April/072079.html , 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.

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

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

[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 ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359) 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/libmythavformat.so.52 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 ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359 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.

[andrew@…]

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

[andrew@…]

script to find files containing cmov instructions below the current directory

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

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

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

and

#CFLAGS=""
#CXXFLAGS=""

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.