some applications using libmpeg encontoured problems on architectures not supporting MMX. I compiled myself mplayer and transcode on Alpha, and dvd::rip master cluster control reports for Alpha nodes: Sun Mar 26 13:39:08 2006 [1] Job has PID 12119 Sun Mar 26 13:39:11 2006 [1] Aborting command. Sending signal 1 to PID 12119... Sun Mar 26 13:39:11 2006 [1] Aborting job: transcode video chunk 1/11, pass 1, psu 0 on node piou_01 Sun Mar 26 13:39:11 2006 [1] Last output of job was: [decode_mpeg2.c] libmpeg2 acceleration: mmx on node piou_01 in practice, on that computer, locate libmpeg2 reports: /usr/lib/libmpeg2.so then, # equery b /usr/lib/libmpeg2.so [ Searching for file(s) /usr/lib/libmpeg2.so in *... ] media-libs/libmpeg2-0.4.0b (/usr/lib/libmpeg2.so -> libmpeg2.so.0.0.0) so ... whatever I put USE="mmxext" or USE="-mmxext" log file of emerge ( /var/log/portage/1267-libmpeg2-0.4.0b.log and /var/log/portage/1327-libmpeg2-0.4.0b.log ) both show same lines asking GCC to use MMX. README file or /usr/portage/distfiles/mpeg2dec-0.4.0b.tar.gz reports in the Portability section: when we use platform-specific optimizations (typically assembly routines [...] we always have a generic C routine to fall back on. [...] Assembly-optimized implementations are available on x86 (MMX) and ppc (altivec) architectures. This means that the dependency upon MMX CPU flag is optionnal, thus, the ebuild should offer a GEntoo USE flag for that. This bug actually occurs on processor EV56, and it should be possible to reproduce on x86 arch with Pentium.1 (except Pentium Pro that may have psuedo MMX instructions), and AMD processors before K5. *** *** *** The fact ./configure does not detect MMX compliance worries me a bit about upstream who seem not to probe that at all at compile tile, and dont seem to offer make option despite of explanations in README. *** *** *** Any one could remind me the commands to check the CPU flags required to run an ELF file ? that would help a lot to reproduce/debug on non Alpha arch, like P.1 and 486 ...or maybe even old Sparc ? *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** # emerge --info Portage 2.0.54 (default-linux/alpha/2005.0, gcc-3.3.2, glibc-2.3.5-r3, 2.6.14.2_plop_piou_SMP alpha) ================================================================= System uname: 2.6.14.2_plop_piou_SMP alpha EV56 Gentoo Base System version 1.6.14 distcc 2.18.3 alpha-unknown-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r4 ACCEPT_KEYWORDS="alpha" AUTOCLEAN="yes" CBUILD="alpha-unknown-linux-gnu" CFLAGS="-mieee -O2 -mcpu=ev56 -pipe" CHOST="alpha-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mieee -O2 -mcpu=ev56 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks keeptemp sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j7" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="alpha X a52 aac aalib acpi aim alsa amuled apache2 arts audiofile bash-completion berkdb bidi bitmap-fonts bl bmp bonjour bootsplash bzip2 cdda cdparanoia cdr cpudetection crypt cups curl dga doc dts dv dvb dvd dvdread dynamic eds encode esd ethereal examples exif expat fam fbcon ffmpeg flac flash font-server foomaticdb fortran freetype gd gdbm ggi gif glut gnutls gpm gs gstreamer gtk gtk2 httpd i8x0 icq idn ieee1394 imlib ipv6 irc jabber javascript jpeg lcms libcaca libg++ libwww lirc listentcp live lj logrotate lzo mad mikmod mng motif mozcalendar mp3 mpeg mplayer msn mtyhtv ncurses network nls no-htdocs nsplugin ogg oggvorbis opengl oss pam pcre pdflib perl png python qt quicktime rar readline real rss rtc samba screen sensord silc skey skins sndfile speex spell ssl stream subtitles svg swat symlink tcpd tetex tga theora threads tiff truetype truetype-fonts type1-fonts udev unicode urandom v4l v4l2 vcd vim vlm vorbis wmf wxwindows xanim xinerama xml2 xmms xosd xscreensaver xv xvid xvmc yahoo zeroconf zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** # cat /proc/cpuinfo cpu : Alpha cpu model : EV56 cpu variation : 7 cpu revision : 0 cpu serial number : system type : Rawhide system variation : Dodge system revision : 0 system serial number : BT00000000 cycle frequency [Hz] : 532813604 est. timer frequency [Hz] : 1200.00 page size [bytes] : 8192 phys. address bits : 40 max. addr. space # : 127 BogoMIPS : 1065.48 kernel unaligned acc : 0 (pc=0,va=0) user unaligned acc : 0 (pc=0,va=0) platform string : AlphaServer 4100 5/533 4MB cpus detected : 3 cpus active : 3 cpu active mask : 0000000000000007 L1 Icache : 8K, 1-way, 32b line L1 Dcache : 8K, 1-way, 32b line L2 cache : 96K, 3-way, 64b line L3 cache : 4096K, 1-way, 64b line
x86-specific issue.
The problem is libmpeg2's very broken configure script wrt CPU detection and configuration. There seem to be fixes in Debian's patches and in CVS: http://ftp.debian.org/debian/pool/main/m/mpeg2dec/mpeg2dec_0.4.0b-4.diff.gz Try adding the following to your ebuild at line 52 and recompiling: use alpha && myconf=" --disable-accel-detect"
yes: x86 specific issue FOR NON x86 HOTS !!! I am gonna test whats proposed in #2 in a few days.
(In reply to comment #1) > x86-specific issue. > I agree this is a x86-specific issue, but I cant figure why the bug have been assigned to Gentoo Developers for the x86 Architecture <x86@gentoo.org> this this bug concerns people NOT using x86 !!! I have altered my ebuild for libmpeg; I now got rougly the same problem, with a different error message: $ transcode -H 10 -x vob,null -i /mnt/SNIP/vob/001/ -w 1204,50 -f 25 -Y 56,8,56,8 -Z 768x432 -R 2 -y xvid4,null -o /mnt/SNIP/avi/001/chunks-psu-00/SNIP-001-00005.avi --print_status 20 -S 00 -W 00005,11,/mnt/SNIP/tmp/SNIP-001-nav.log && echo EXECFLOW_OK || echo BLOK ( I added BLOK myself ...) => [export_xvid4.so] Neither './xvid4.cfg' nor '~/.transcode/xvid4.cfg' [export_xvid4.so] found. Default settings will be used instead. tc_memcpy: using libc for memcpy (demuxer.c) seeking to sequence 0:0 ... [decode_mpeg2.c] libmpeg2 0.4.0b loop decoder [decode_mpeg2.c] libmpeg2 acceleration: none (plain C) Floating point exception BLOK dhp@piou $ sh: line 1: 8253 Broken pipe tccat -i "/mnt/SNIP/vob/001/" -t vob -d 0 -S 855501 8254 | tcdemux -s 0x80 -x mpeg2 -S 0,0-671 -M 1 -d 0 8255 | tcextract -t vob -a 0 -x mpeg2 -d 0 8256 | tcdecode -x mpeg2 -d 0 -y yv12 so, no MMX problem any more, but FPexp !!! is this ebuild known to work on ARM, Sparc and PPC ?
(In reply to comment #2) > There seem to be fixes in Debian's patches and in CVS: > http://ftp.debian.org/debian/pool/main/m/mpeg2dec/mpeg2dec_0.4.0b-4.diff.gz how can I make my ebuild use it ? put patch in portage ? re-run ebuild(1) ?
Sorry, I'm x86 and not very experienced with autotools, so I can't diagnose this problem. Alpha should work - if it was stabilized then someone tested it - perhaps a recent change to the ebuild has caused it to break?
I fail how to see a configure cpu detection problem is a x86 bug? If you can explain how that is more power to you.
./configure scripts have been designed to test/detect arch specific features; in example, thats why ./configure is essentially (by essence of design) a SCRIPT, and not an executable binary ! => if configure fails to see on Alpha that MMX is not available, that *is* a ./configure problem, cause ./configure *is* responsible for Makefile generation, and code optimisation and feature activation Thats why I ask to non-x86 and non-Alpha people to tell me if they get MMX problem or not ... that will tell us "how" ./configure is broken ... then, we know if the bug is Alpha specific, x86 specific, or arch independent. That a case where PPC ans Sparc may help to fix x86 vs Alpha problem :) New ARM may also be interesting since from memory, some ARM have MMX :) there, disabling MMX GCC optimisation (for inst set optimisation) would be stupid), but if configure only reads the CPU flags and activates ASM MMX x86 optimised functions on non x86, but still MMX capable architectures, that would become funny :D
What do you think about incorporating the changes the mplayer-devs did to libmpeg2? http://svn.mplayerhq.hu/mplayer/trunk/libmpeg2/ There is also a patch libmpeg-0.4.0.diff but it produces one reject against libmpeg2-0.4.0b.
Please test what happens when using media-libs/libmpeg2-0.4.1
Topic is on fire. I need some video under Lirbart for this test. Will take time since Gentoo is not on my Alpha any more, and all my disks are busy because of multiple other bugs (mkinitrd, and losetup are broken on the dist actualy installed) ... Can not re-install gentoo before QLA1040 kernel bug is solved (that means: buy non-Qlogic card). Topic on fire = hopefully can deal libmpeg bug within 2 to 4 weeks.
Status on this?
(In reply to comment #11) > Topic is on fire. I need some video under Lirbart for this test. > > Will take time since Gentoo is not on my Alpha any more, and all my disks are > busy because of multiple other bugs (mkinitrd, and losetup are broken on the > dist actualy installed) ... LATER ... (no need to keep this open). I will come back here after I test whats proposed.
