emerge mplayer bombs out like so : gcc -I../libvo/ -I../../libvo -O4 -march=pentium4 -mcpu=pentium4 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o msmpeg4.o msmpeg4.c msmpeg4.c: In function `msmpeg4_pred_dc': msmpeg4.c:735: error: can't find a register in class `BREG' while reloading `asm' make[1]: *** [msmpeg4.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/mplayer-1.0_pre4/work/MPlayer-1.0pre4/libavcodec' make: *** [libavcodec/libavcodec.a] Error 2 !!! ERROR: media-video/mplayer-1.0_pre4 failed. !!! Function src_compile, Line 259, Exitcode 2 !!! Failed to build MPlayer! eater root # emerge --info Portage 2.0.50-r6 (hardened-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.6.5-gentoo-r1) ================================================================= System uname: 2.6.5-gentoo-r1 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.4.10 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -pipe -O3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -pipe -O3 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.is.co.za/linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa arts avi berkdb crypt cups dvd esd ethereal flac hardened imlib ipv6 java jpeg kde md5sum motif mozilla mpeg msn nls oggvorbis opengl pam perl pic pie png python qt readline samba sdl spell ssl tcpd usb video_cards_radeon x86 xmms xv zlib" i have tried compiling using -O and pentium3 and even just -O. Adding -hardened and\or -fPIC and\or -DPIC to the USE flags doesnt help. I did a deep scan of all my dependancies to make sure the rest of my system is solid and it is. Maybe worth nothing that ffmpeg also fails with this error. Please help! dre
smells like hardened to me. throwing it over there.
*** Bug 52587 has been marked as a duplicate of this bug. ***
How many times must mplayer/xine/openoffice haunt us. Anyway filter-flags -fPIC fixes this. solar@simple mplayer $ grep fPIC * ChangeLog: removed hardened-gcc logic, added filter-flags fPIC logic ChangeLog: update -fPIC handling for post-hardened-gcc ChangeLog: Update -fPIC filtering magic for post hardened-gcc. mplayer-0.92-r1.ebuild: filter-flags -fPIC mplayer-1.0_pre2-r1.ebuild: filter-flags -fPIC mplayer-1.0_pre3-r3.ebuild: filter-flags -fPIC mplayer-1.0_pre3-r4.ebuild: filter-flags -fPIC mplayer-1.0_pre3-r5.ebuild: filter-flags -fPIC mplayer-1.0_pre4-r1.ebuild: filter-flags -fPIC mplayer-1.0_pre4-r2.ebuild: filter-flags -fPIC mplayer-1.0_pre4-r3.ebuild: filter-flags -fPIC mplayer-1.0_pre4-r4.ebuild: filter-flags -fPIC mplayer-1.0_pre4.ebuild: filter-flags -fPIC
*** Bug 49454 has been marked as a duplicate of this bug. ***
USE="-mmx" or -fPIC dont help (as i read in a few other posts). Maybe this is of some use to someone.... eater root # gcc --version gcc (GCC) 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. spoke to the guys #mplayerdev and they suggested i use gcc 3.4, but i dont see myself doing that to my system anytime soon :)
err sorry it's not -mmx I've overworked and underpaid. ssp will cause GENERAL_REGS reloading asm not the one you had. error: can't find a register in class `BREG' while reloading `asm' is caused by mplayer's code not being pic aware with the ebx register. Some combo if -fno-pic will work (has to work) Give this a try. CFLAGS="-fno-pic" emerge mplayer # this really would be happening for you automatic but your using a dated version of gcc so no guarentee's Really you need to be at gcc-3.3.3-r5 to be on track. And no gcc-3.4 does not fix squat.
CFLAGS="-fno-pic" emerge mplayer gives the same gcc -I../libvo/ -I../../libvo -O4 -march=pentium4 -mcpu=pentium4 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o msmpeg4.o msmpeg4.c msmpeg4.c: In function `msmpeg4_pred_dc': msmpeg4.c:735: error: can't find a register in class `BREG' while reloading `asm' make[1]: *** [msmpeg4.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/mplayer-1.0_pre4/work/MPlayer-1.0pre4/libavcodec' make: *** [libavcodec/libavcodec.a] Error 2 !!! ERROR: media-video/mplayer-1.0_pre4 failed. !!! Function src_compile, Line 269, Exitcode 2 !!! Failed to build MPlayer! i would like to upgrade to gcc 3.3.3 and have been trying for about 4 days now bash-2.05b# emerge -pv /usr/portage/sys-devel/gcc/gcc-3.3.3-r5.ebuild These are the packages that I would merge, in order: Calculating dependencies ...done! [blocks B ] sys-devel/hardened-gcc (from pkg sys-devel/gcc-3.3.3-r5) [ebuild U ] sys-devel/gcc-3.3.3-r5 [3.3.2-r5] +X -bootstrap -build -debug -f77 -gcj +hardened +java -multilib +nls -objc -static -uclibc 13 kB bash-2.05b# ls /usr/portage/ | grep hardened gives me nothing. so its being blocked by something that isnt there........ thanks for the help so far, keep up the food work! :) dr_dre
[blocks B ] sys-devel/hardened-gcc (from pkg sys-devel/gcc-3.3.3-r5) hardened-gcc has been obsoleted.. You should remove it. emerge -C hardened-gcc gcc -dumpspecs > `gcc-config -L`/specs emerge mplayer ACCEPT_KEYWORDS="~x86" emerge =sys-devel/gcc-3.3.3-r5 ---------------------------------------------------------------------------- ok.. mplayer you nasty thorn in our sides.. This is a QA problem really. MPlayer-1.0pre4/libavcodec is a shared object and it's not a PIC aware. This is violates an internal policy that requires all shared objects to be compiled properly with -fPIC. Reassigning bug to media-video and adding qa@ to the CC to oversee that this actually gets fixed.
emerge -C hardened-gcc gcc -dumpspecs > `gcc-config -L`/specs emerge mplayer somehow that worked and mplayer compiled using my old gcc. i think i love you :) gonna upgrade my gcc tonight try again tomorrow to see what happens. thank you very very guys!
I just took a closer look at this... The source code seems to be wrong. old libtool style infact. I'll test this in a few mins. -#if defined ARCH_X86 && !defined PIC +#if defined ARCH_X86 && !defined __PIC__ Also worth a note is this ebuild does not have mmx in it's IUSE but makes use of the mmx USE flag.
Well that helped make it further, but we not quite there yet.. env USE="-*" ebuild mplayer-1.0_pre4-r4.ebuild clean unpack compile gcc -DPIC -c -I../libvo/ -I../../libvo -O4 -march=pentium4 -mcpu=pentium4 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -o imdct.o imdct.c imdct.c: In function `imdct_do_512_sse': imdct.c:937: warning: use of memory input without lvalue in asm operand 1 is deprecated imdct.c:937: warning: use of memory input without lvalue in asm operand 2 is deprecated imdct.c:784: error: can't find a register in class `BREG' while reloading `asm' make[1]: *** [imdct.o] Error 1 make[1]: Leaving directory `/var/cvsroot/tmp/portage/mplayer-1.0_pre4-r4/work/MPlayer-1.0pre4/liba52' make: *** [liba52/liba52.a] Error 2
More QA problems here. If the user has matrox in the USe flags and is using 2.6.x he/she will have his/her /usr/src/linux/.conifg backed up to a temp dir but if the user does a crtl+c or the .ebuild fails for some reason then chances are it will not be restored. This code has to go.. Can somebody from our QA team review this please http://www.gentoo.org/cgi-bin/viewcvs.cgi/media-video/mplayer/mplayer-1.0_pre4-r3.ebuild?r1=1.4&r2=1.5&hideattic=1
Solar, I'm going to yank the matrox/kernel crap when I finish off adding/testing patches for pre4-r5. The matrox/kernel code will be removed through out each version- it'll just throw a complaint stating 'sorry, you want this module w/ support, compile your kernel w/ it on'. Need to do testing of this (and write the code).
Created attachment 34399 [details, diff] mplayer-1.0_pre4-fpic-fun.patch v1 Solar, this is the patch you took for a spin- both chris white and myself haven't had issues with it. I'd be curious if this solves issues for others- meanwhile, I'd like to pin down why compilation is still failing for you w/ this patch. Unless this takes ungodly long, I'd prefer to get mplayer behaving correctly -fPIC wise for 1.0_pre4-r5.
The patch posted in the comment above helps, but the build breaks a bit later instead: gcc -c -I../libvo/ -I../../libvo -O4 -march=athlon -mcpu=athlon -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -Inative -I.. -I../libmpdemux -I../loader -D_GNU_SOURCE -o vf_tfields.o vf_tfields.c vf_tfields.c: In function `qpel_4tap_MMX': vf_tfields.c:199: error: can't find a register in class `BREG' while reloading `asm' make[1]: *** [vf_tfields.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/mplayer-1.0_pre4-r8/work/MPlayer-1.0pre4/libmpcodecs' make: *** [libmpcodecs/libmpcodecs.a] Error 2 Also, the patch clashes with the mplayer-odml.patch (can't apply them both).
Created attachment 36765 [details, diff] mplayer-1.0_pre5-fpic.patch Version of the patch above for 1.0pre5. Basically offset fixes and removal of odml part which I think sneaked into the 1.0pre4 patch by mistake (and it's fixed in 1.0pre5 anyway). The build still fails later in the same place as explained in my previous comment.
Can somebody mail upstream and have them look at this bug? By the time we end up patching all the mplayer PIC problems the diff will be so off from the upstream code that things will likely end up causing problems later on down the line. Note: for the mplayer team. I can provide you with gcc specs that you can use to do proper fPIC testing.
How about simply disabling -fPIC and other 'hardened' compiler options in the ebuild for now, and build mplayer as a "normal" executable (until this has been fixed upstream).
Not sure about you but I don't like pretending a bug does not exist. When we work around these types of bugs they get forgotten about. And as long as it continues to break users will contine to search bugzilla and continue to offer patches. If the majority would just assume pretend the bug does not exist I won't stop anybody from doing a work around. (I'm just not in favor of it) Sounds crazy but this is what drives OSS forward.
I could be missing something, but until a week ago, we did not add -fPIC to CFLAGS, or could it be added. Or does hardened add it via specs? If so, what is the drawbacks of disabling it? Stupid question - whats up with the custom CFLAGS in latest revision? The mplayer devs is really hard-assed about setting funny CFLAGS, and the defaults is already (or was in past) a bit insance for some broken archs ...
Overlooked this one. Yes Martin the hardened toolchain enables fPIC/fpic in the *cc1: section of the gcc specs. Basic logic for x86 is as. %{!shared: %{!nostdlib: %{!nostartfiles: %{!fno-PIE: %{!fno-pie: %{!nopie: %{!fPIC:%{!fpic:-fPIE}}} } } } } } } } }
The custom CFLAGS should be (?) package.masked. It was created as I was getting bombarded left and right with requests for custom CFLAGS being enabled. Therefore I did that for everyone's happiness. The package.mask since I didn't know the upstream/downstream effects it would have on an "official release".
Created attachment 40033 [details, diff] pic patch - some assembler hacking This patch (applied manually with patch -p1 in the ebuild work directory) gets mplayer to build, at least on my system. Whilst this now builds, so far I've only managed to get it to play Ogg files - mp3s, dvds, wavs all crash. Some description to follow.
The patch I've just added above (against r5-p3 btw), includes the PIC -> __PIC__ changes, but additionally reworks some assembler bits. The "BREG" error means that the compiler doesn't have ebx free for allocation to parameters, so it needs mangling somewhat. Most of the patches are alterations along these lines. The method I've used here, is to save ebx to a static global, and restore from there afterwards, changing the "b" parameter to a general register ("g"). They're all surrounded by #ifd{n}ef __PIC__ so they're easy to follow. Note that this technique doesn't work for re-entrant or recursive code. One file caused more fun/trouble - mp3lib/tabinit_MMX.c I'm not confident I've got the changes here correct - it's far from clear what the code is supposed to be doing. This may also be related to compiler versions; some of the constructs the mplayer team are using are marked as deprecated, which presumably was not the case when they wrote it. Unfortunately, as I said above, it crashes for me when trying to play mp3s, wavs or dvds. Trying to build with debug causes it to bring in lots of non-PIC code (I guess it switches off PIC!), quite a bit of which is rather hairy. As a result, I haven't been able to locate the crash site yet. The save-to-static-global trick is not always the best method; sometimes simply doing pushl/popl instead works. I'm going to try the pushl/popl approach, to see if it gets any better but I doubt it. The reason I went for the save-to-static-global first is that it worked on another package when pushl/popl didn't, but that was a rather special case. Lastly, I've only patched the files the compiler rejected during build. There may be others that need patching, especially if the clobber lists are wrong; the sort of error that sometimes doesn't cause a problem depending on what register allocation the compiler made at the time.
Created attachment 40038 [details, diff] pic patch against pre5-r4 - push/pop version Woohoo - just tried my patch against pre5-r4 (instead of pre5-r3) and it now plays Ogg, Wav, mp3, and dvds! I guess -r3 was busted. This patch does the same thing, but using pushl/popl instead - I think it's tidier, for this package - it's a little smaller, too. Time for some testing and review!
Cool testing this one shortly. I'll ask the PaX Author(asm guru) who has been so helpful in the past to take a peek at your updated patch for your request of a review.
gcc -I../libvo -I../../libvo -I/usr/X11R6/include -march=i686 -mtune=i686 -O3 -pipe -fforce-addr -Wformat=2 -m32 -fno-stack-protector -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o motion_est.o motion_est.c motion_est_template.c: In function `hpel_motion_search': motion_est_template.c:176: error: can't find a register in class `GENERAL_REGS' while reloading `asm' .... (this goes on till line 212) make[1]: *** [motion_est.o] Error 1 make[1]: Leaving directory `/space/portage-tmp/portage/mplayer-1.0_pre5-r4/work/MPlayer-1.0pre5/libavcodec' -------------------------------------------------------------------------------- I've only seen this happen with fstack-protector and ssp in the past. I'm on my 7th run here and can't quite seem to filter this one out. -------------------------------------------------------------------------------- [ebuild U ] media-video/mplayer-1.0_pre5-r4 [0.92] +3dfx* -3dnow* -3dnowex +X +aalib -alsa -altivec -arts -bidi -cdparanoia -debug -directfb -divx4linux -doc -dvb +dvd* +dvdread* -edl +encode +esd* -fbcon -ggi +gif* +gtk* -i8x0 -ipv6 -jack -joystick +jpeg -libcaca -lirc -live +lzo* +mad -matroska -matrox -mmx* -mmx2 +mpeg -mythtv -nas -network -nls* +nvidia* +oggvorbis +opengl +oss +png -rtc -samba +sdl +sse -sse2* +svga -tga -theora +truetype +v4l* -v4l2 +xinerama +xmms +xv +xvid* -xvmc 0 kB -------------------------------------------------------------------------------- gcc version 3.4.1 20040803 (Gentoo Hardened Linux 3.4.1-r3, ssp-3.4-2, pie-8.7.6.5) -------------------------------------------------------------------------------- Kevin what did you build with? CFLAGS/USE FLAGS/gcc/binutils/etc ?
Created attachment 40055 [details] output of emerge info Output of emerge info attached. System is an AMD athlon-xp. gcc -v gives: Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs Configured with: /var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++,java --enable-threads=posix --enable-long-long --disable-checking --disable-libunwind-exceptions --enable-cstdio=stdio --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-interpreter --enable-java-awt=xlib --with-x --disable-multilib --enable-__cxa_atexit --enable-clocale=generic Thread model: posix gcc version 3.3.4 20040623 (Gentoo Hardened Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) The file it fails on for you is included only when I try to build with "debug". You can get it to build by adding "&& !defined(__PIC__)" to line 1236 of libavcodec/common.h: #if __CPU__ >= 686 && !defined(RUNTIME_CPUDETECT) && !defined(__PIC__) so it'll use alternative C code instead of inline assembler. The resulting change in assembly in the object code for me is from: cmpl %ebx, %eax cmovl %eax, %ebx cmovl %edx, %esi cmovl %ecx, %edi movl %ebx, 2684(%esp) movl 2420(%esp), %ebx movl %edi, 2588(%esp) movl %esi, 2596(%esp) cmpl %ebx, 2428(%esp) jg .L134 to cmpl 2684(%esp), %eax jge .L134 movl 2404(%esp), %ebx movl 2400(%esp), %esi movl %eax, 2684(%esp) movl %ebx, 2596(%esp) movl %esi, 2588(%esp) .L134: movl 2420(%esp), %edi cmpl %edi, 2428(%esp) jg .L135 so the only saving is three stack memory accesses vs register anyway. When building with debug, it next fell over building libpostproc - the stuff it brings in from there is not so easy to fix; however it does have support for building as a shared library already and it ought to use that. My understanding of the "GENERAL_REGS" error is that the compiler has run out of registers to use in parameters - in my case don't run out of registers, it uses that inline asm without problem. It could well be due to compiler version.
Ah; bad news - in config.mak on my p4 work directory, -fno-pic and -nopie are set in OPTFLAGS. This didn't happen on p3. First, this explains why everything "works" so easily in p4. Secondly it's not a solution, so it needs to be undone. Can't find where they have come from - it's as if they're being set by the ebuild scripts before running configure but I can't see it. I'll investigate properly this evening.
Created attachment 40101 [details, diff] mplayer-1.0_pre5-r4.ebuild.diff Yeah that could be a pesky one to trace down. It however comes from the filtering of fPIC/fPIE when using the hardened toolchain. less $(portageq envvar PORTDIR)/eclass/flag-o-matic.eclass ; # for more details. My attached diff corrects that behavior and was what I used to test (saved your patch to files/mplayer-1.0_pre5-x86-pic.patch
I'm assuming that pic patch against pre5-r3 and pic patch - some assembler hacking are the ones that are required correct? Please slap me with a wet trout if I have that wrong... I may also have to investigate these patches with other programs. ffmpeg, transcode, MPLayer, and now xine (optional) can utilize ffmpeg, which is where the root core of the problem lies (It's not really specific to MPlayer, it's specific to ffmpeg inside of MPlayer). Hopefully, that will fix media-video/* that depends on ffmpeg internally or externally. And a big giant THANK YOU for patching this stuff that has been driving me up the wall for the longest time now :).
Re comment #31 slow down. There is no working patch on this thread yet.
*** Bug 76730 has been marked as a duplicate of this bug. ***
*** Bug 73254 has been marked as a duplicate of this bug. ***
I had this problem, and fixed it for me by adding -fomit-frame-pointer to my Cflags. I see others have that already so not a general fix. My line in make.conf CFLAGS="-O3 -march=athlon-tbird -funroll-loops -pipe -fomit-frame-pointer " I found if I downloaded the source from www.mplayerhq.hu/ that compiled OK, and the omit-frame-pointers was the critical diff.
/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -o crc.o crc.c cc -c -I../libvo -I../../libvo -I/usr/X11R6/include -march=pentium4 -fno-pie -fno-pie -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -o resample.o resample.c cc -c -I../libvo -I../../libvo -I/usr/X11R6/include -march=pentium4 -fno-pie -fno-pie -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -o bit_allocate.o bit_allocate.c cc -c -I../libvo -I../../libvo -I/usr/X11R6/include -march=pentium4 -fno-pie -fno-pie -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -o bitstream.o bitstream.c cc -c -I../libvo -I../../libvo -I/usr/X11R6/include -march=pentium4 -fno-pie -fno-pie -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -o downmix.o downmix.c cc -c -I../libvo -I../../libvo -I/usr/X11R6/include -march=pentium4 -fno-pie -fno-pie -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -o imdct.o imdct.c In file included from imdct.c:757: imdct_3dnow.h: In function `fft_asmb_3dnow': imdct_3dnow.h:241: error: can't find a register in class `GENERAL_REGS' while reloading `asm' imdct.c: In function `imdct_do_512_sse': imdct.c:937: warning: use of memory input without lvalue in asm operand 1 is deprecated imdct.c:937: warning: use of memory input without lvalue in asm operand 2 is deprecated make[1]: *** [imdct.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/mplayer-1.0_pre5-r5/work/MPlayer-1.0pre5try2/liba52' make: *** [liba52/liba52.a] Error 2 !!! ERROR: media-video/mplayer-1.0_pre5-r5 failed. !!! Function src_compile, Line 463, Exitcode 2
*** Bug 83241 has been marked as a duplicate of this bug. ***
Created attachment 53916 [details] mplayer-1.0_pre6-r2.ebuild Ebuild....
Created attachment 53917 [details, diff] mplayer-1.0_pre6-pic.patch And the gorey patch. Put the 2 together and profit! Just tried it after 3 hours of BREG errors and it WORKSFORME. Didn't get a chance to runtime test though.. I'm going to sleep @_@
Thank GOD I can finally close this. Ok, so I had to disable mp3lib internal support in mplayer, because that was the only thing that wasn't working. No, you can still listent o mp3 audio, it will just be using mplayer's internal ffmpeg mp3 decoder instead (which works). A little explanation of how things got accomplished: 1) PIC -> __PIC__ (we all knew that one) 2) remove ebx from clobber list: http://my.execpc.com/~geezer/osd/gotchas/ for explanation 3) make stuff actually conditional that should be 4) alter the imdct.c that was user provided (T-H-A-N-K Y-O-U) 5) use ffmpeg internal mp3 decoder instead of mp3lib and profit! Bug closed :D
Does anybody else sees this jump in CPU usage going from mp3lib to ffmpeg mp3 decoder? Playing mp3 files in mplayer with mp3lib I could not even notice it in top now with ffmpeg it uses about 4%. Is it really necessary to disable mp3lib? How come mplayer-1.0_pre6-r2 compiles here with mp3lib? (I just commented a line with --disable-mp3lib in the ebuild)
Hmm; just looking at the patch, the imdct part at least is broken: +#ifdef __PIC_ "movlps (%0, %%esi), %%xmm0 \n\t" // XXXI "movhps 8(%0, %%edi), %%xmm0 \n\t" // RXXI "movlps 8(%0, %%esi), %%xmm1 \n\t" // XXXi "movhps (%0, %%edi), %%xmm1 \n\t" // rXXi +#else + "movl %[data], %%ebx\n\t" + "movlps (%%ebx, %%esi), %%xmm0\n\t" + "movhps 8(%%ebx, %%edi), %%xmm0\n\t" + "movlps 8(%%ebx, %%esi), %%xmm1\n\t" + "movhps (%%ebx,%%edi), %%xmm1\n\t" +#endif is ineffective because the #ifdef has a typo (should be __PIC__ not __PIC_). It'll compile, because there's nothing syntactically wrong with the original code (which is what gets built), and the patch removes the clobber of ebx. However semantically the code is wrong as the clobber list is not consistent with that code - unexpected behaviour may result.
