Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 142380 - media-video/ffmpeg-0.4.9_p20060530 fails to build with USE="mmx"
Summary: media-video/ffmpeg-0.4.9_p20060530 fails to build with USE="mmx"
Status: VERIFIED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Developers for the x86 Architecture
URL: http://article.gmane.org/gmane.comp.v...
Whiteboard:
Keywords:
: 136171 142385 142463 142641 142898 143017 143027 143187 143281 143864 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-08-01 00:31 UTC by Dominik Strehlke
Modified: 2007-03-16 09:35 UTC (History)
69 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch snowdsp_mmx.c to avoid or restore ebx (ffmpeg-snow-mmx.patch,9.69 KB, patch)
2006-08-02 13:07 UTC, Martin von Gagern
Details | Diff
patch mmx.h to use ebp instead of ebx as REG_b in PIC mode (ffmpeg-PIC-ebp.patch,402 bytes, patch)
2006-08-07 15:00 UTC, Martin von Gagern
Details | Diff
ebuild patch to remove PIC for the special case of MMX+x86 (ffmpeg-0.4.9_p20060530.ebuild.patch,442 bytes, patch)
2006-08-09 14:15 UTC, Pierre Poissinger
Details | Diff
Patch to snowdsp_mmx.c (snowdsp_mmx-5.diff,10.37 KB, patch)
2006-08-10 09:18 UTC, Martin von Gagern
Details | Diff
Ebuild with patch for snowdsp_mmx (ffmpeg-0.4.9_p20060530-r1.ebuild.tar.gz,6.88 KB, application/octect)
2006-08-14 03:30 UTC, Antony Mee
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dominik Strehlke 2006-08-01 00:31:16 UTC
Compiler output:
i686-pc-linux-gnu-gcc -Wall -Wno-switch -O2 -fomit-frame-pointer -fomit-frame-pointer -DHAVE_AV_CONFIG_H -I.. -I/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-shared/libavutil -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE  -fPIC -DPIC -c -o i386/snowdsp_mmx.o i386/snowdsp_mmx.c
i386/snowdsp_mmx.c: In function 'ff_snow_vertical_compose97i_sse2':
i386/snowdsp_mmx.c:461: error: PIC register '%ebx' clobbered in 'asm'
i386/snowdsp_mmx.c: In function 'ff_snow_vertical_compose97i_mmx':
i386/snowdsp_mmx.c:568: error: PIC register '%ebx' clobbered in 'asm'
i386/snowdsp_mmx.c: In function 'inner_add_yblock_bw_8_obmc_16_mmx':
i386/snowdsp_mmx.c:869: error: PIC register '%ebx' clobbered in 'asm'
make[1]: *** [i386/snowdsp_mmx.o] Error 1
make[1]: Leaving directory `/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-shared/libavcodec'
make: *** [lib] Error 2

localhost old # emerge --info
Portage 2.1.1_pre4-r1 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.17-gentoo-r4 i686)
=================================================================
System uname: 2.6.17-gentoo-r4 i686 Intel(R) Pentium(R) M processor 2.00GHz
Gentoo Base System version 1.12.1
app-admin/eselect-compiler: 2.0.0_rc2-r1
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.17
sys-devel/gcc-config: 2.0.0_rc1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X aac alsa apache2 apm arts avi berkdb bitmap-fonts cdr cli crypt cups dlloader dri dvb dvd dvdr eds emboss encode esd exif foomaticdb fortran gdbm gif gpm gstreamer gtk2 i810 imlib ipv6 isdnlog jpeg kde kdeenablefinal libg++ libwww mad mikmod mmx motif mp3 mpeg mysql ncurses nls nptl nptlonly nsplugin ogg opengl oss pam pcre pdflib perl png pppd python qt qt3 qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl tcpd truetype truetype-fonts type1-fonts udev vorbis win32codecs xml xmms xorg xv xvid zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux userland_GNU video_cards_i810"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Comment 1 Arne Flagge 2006-08-01 00:36:38 UTC
Same here.

Portage 2.1.1_pre4-r1 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3
, 2.6.17-gentoo-r4 i686)
=================================================================
System uname: 2.6.17-gentoo-r4 i686 AMD Athlon(tm) XP 3200+
Gentoo Base System version 1.12.1
ccache version 2.4 [enabled]
app-admin/eselect-compiler: 2.0.0_rc2-r1
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r2
dev-util/confcache:  0.4.2-r1
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.17
sys-devel/gcc-config: [Not Present]
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shu
tdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gcon
f /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf
/web2c"
CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch sandbox s
fperms strict"
GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://distf
iles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LANG="de_DE@euro"
LC_ALL="de_DE@euro"
LINGUAS="de"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress                                                               --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/d                                                              istfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/vmware"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="x86 3dnow 3dnowext X a52 aac acpi alsa apache2 apm arts avi bash-completion                                                               berkdb bitmap-fonts bluetooth bzip2 cairo cdparanoia cli crypt css cups curl db                                                              us dlloader dvd dvdr dvdread emboss ffmpeg firefox foomaticdb fortran gdbm gtk2                                                               hal hbci howl isdnlog jpeg kde kdeenablefinal kdehiddenvisibility libg++ libwww                                                               lm_sensors mad mmx mmxext mozcalendar mozsvg mp3 mpeg mplayer musicbrainz ncurse                                                              s nls nptl nsplugin nvidia ogg opengl pam pcre pdf pdflib perl pic png pppd prof                                                              ile python qt qt3 quicktime readline real reflection samba session slang slp spe                                                              ll spl sse ssl svg tcpd threads truetype truetype-fonts type1-fonts udev vorbis                                                               win32codecs x264 xml xorg xv xvid xvmc zlib elibc_glibc input_devices_keyboard i                                                              nput_devices_evdev kernel_linux linguas_de userland_GNU video_cards_none video_c                                                              ards_nvidia video_cards_nv"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, MAKEOPTS
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2006-08-01 02:07:27 UTC
*** Bug 142385 has been marked as a duplicate of this bug. ***
Comment 3 Martin von Gagern 2006-08-01 06:41:45 UTC
USE=-mmx makes things work. This looks like a gcc-4.1.1 issue to me.
Comment 4 Peter J. de Vrijer 2006-08-01 07:03:38 UTC
I use gcc 3.4.6 and have the same problem.
Comment 5 Samuli Suominen gentoo-dev 2006-08-01 07:04:34 UTC
Same problem..

i686-pc-linux-gnu-gcc -Wall -Wno-switch -O2 -march=athlon-xp -pipe -g -fomit-frame-pointer -fomit-frame-pointer -DHAVE_AV_CONFIG_H -I.. -I/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-shared/libavutil -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE   -fPIC -DPIC -c -o i386/snowdsp_mmx.o i386/snowdsp_mmx.c
i386/snowdsp_mmx.c: In function 'ff_snow_vertical_compose97i_sse2':
i386/snowdsp_mmx.c:461: error: PIC register '%ebx' clobbered in 'asm'
i386/snowdsp_mmx.c: In function 'ff_snow_vertical_compose97i_mmx':
i386/snowdsp_mmx.c:568: error: PIC register '%ebx' clobbered in 'asm'
i386/snowdsp_mmx.c: In function 'inner_add_yblock_bw_8_obmc_16_mmx':
i386/snowdsp_mmx.c:869: error: PIC register '%ebx' clobbered in 'asm'
make[1]: *** [i386/snowdsp_mmx.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-shared/libavcodec'
make: *** [lib] Error 2

Using..

CFLAGS="-O2 -march=athlon-xp -pipe -g"
CXXFLAGS="${CFLAGS}"
Comment 6 Jochen Schalanda 2006-08-01 07:19:22 UTC
See Bug #136171
Workaround: Disable the mmx useflag
Comment 7 Samuli Suominen gentoo-dev 2006-08-01 07:27:18 UTC
*** Bug 136171 has been marked as a duplicate of this bug. ***
Comment 8 Eike Hein 2006-08-01 07:41:49 UTC
Same here, using GCC 4.1.1.
Comment 9 michel 2006-08-01 08:54:23 UTC
The same here
Comment 11 David Li 2006-08-01 09:00:11 UTC
I believe comment #10 is wrong. I have (and others) fomit-frame-pointer in CFLAGS and still recieve the error. Also, looking at the original bug reporter's comment:

i686-pc-linux-gnu-gcc -Wall -Wno-switch -O2 -fomit-frame-pointer <----
Comment 12 Gene Seto 2006-08-01 09:05:41 UTC
yeah my bad.. i realized that just after i pushed the commit button i should have tested that first. It doesn't work anyways :)
Comment 13 David Li 2006-08-01 09:29:23 UTC
Anyways, their mailing list mentions this bug here:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-April/010294.html
and here:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009600.html

With a proposed fix here:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/008506.html
The proposed fix has very long discussion btw.
Comment 14 Patrick McLean gentoo-dev 2006-08-01 13:18:05 UTC
Reassigning this to the x86 team since this an x86 specific problem.
Comment 15 Jakub Moc (RETIRED) gentoo-dev 2006-08-01 13:37:44 UTC
*** Bug 142463 has been marked as a duplicate of this bug. ***
Comment 16 Francois Chenier 2006-08-01 16:28:46 UTC
Same problem here & works fine without the MMX flag set.

i386/fft_3dn2.c: In function 'ff_fft_calc_3dn2':
i386/fft_3dn2.c:44: warning: implicit declaration of function '_m_femms'
i386/fft_3dn2.c:47: error: '__m64' undeclared (first use in this function)
i386/fft_3dn2.c:47: error: (Each undeclared identifier is reported only once
i386/fft_3dn2.c:47: error: for each function it appears in.)
i386/fft_3dn2.c:47: error: 'r' undeclared (first use in this function)
i386/fft_3dn2.c:47: error: 'a0' undeclared (first use in this function)
i386/fft_3dn2.c:47: warning: left-hand operand of comma expression has no effect
i386/fft_3dn2.c:47: error: 'a1' undeclared (first use in this function)
i386/fft_3dn2.c:47: warning: left-hand operand of comma expression has no effect
i386/fft_3dn2.c:47: error: 'b0' undeclared (first use in this function)
i386/fft_3dn2.c:47: warning: left-hand operand of comma expression has no effect
i386/fft_3dn2.c:47: error: 'b1' undeclared (first use in this function)
i386/fft_3dn2.c:47: warning: left-hand operand of comma expression has no effect
i386/fft_3dn2.c:47: error: 'c' undeclared (first use in this function)
i386/fft_3dn2.c:47: warning: left-hand operand of comma expression has no effect
i386/fft_3dn2.c:47: warning: statement with no effect
i386/fft_3dn2.c:49: error: expected expression before ')' token
i386/fft_3dn2.c:51: error: expected expression before ')' token
i386/fft_3dn2.c:53: error: expected expression before ')' token
i386/fft_3dn2.c:58: warning: implicit declaration of function '_m_pfadd'
i386/fft_3dn2.c:59: warning: implicit declaration of function '_m_pfsub'
i386/fft_3dn2.c:66: warning: implicit declaration of function '_m_pswapd'
i386/fft_3dn2.c:67: warning: implicit declaration of function '_m_pxor'
i386/fft_3dn2.c:91: error: expected ';' before 'a0'
i386/fft_3dn2.c:93: error: expected expression before ')' token
i386/fft_3dn2.c:94: error: expected expression before ')' token
i386/fft_3dn2.c:95: error: expected expression before ')' token
i386/fft_3dn2.c:96: error: expected expression before ')' token
i386/fft_3dn2.c:99: error: 'c0' undeclared (first use in this function)
i386/fft_3dn2.c:99: error: expected expression before ')' token
i386/fft_3dn2.c:100: error: 'c1' undeclared (first use in this function)
i386/fft_3dn2.c:100: error: expected expression before ')' token
i386/fft_3dn2.c:102: error: 't10' undeclared (first use in this function)
i386/fft_3dn2.c:102: warning: implicit declaration of function '_m_pfmul'
i386/fft_3dn2.c:103: error: 't11' undeclared (first use in this function)
i386/fft_3dn2.c:108: error: 't20' undeclared (first use in this function)
i386/fft_3dn2.c:109: error: 't21' undeclared (first use in this function)
i386/fft_3dn2.c:112: warning: implicit declaration of function '_m_pfpnacc'
i386/fft_3dn2.c:116: error: expected expression before ')' token
i386/fft_3dn2.c:117: error: expected expression before ')' token
i386/fft_3dn2.c:118: error: expected expression before ')' token
i386/fft_3dn2.c:119: error: expected expression before ')' token
make[1]: *** [i386/fft_3dn2.o] Error 1
make[1]: Leaving directory `/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-static/libavcodec'
make: *** [lib] Error 2

For both cases (working and not working), my flags in make.conf are ...
CFLAGS="-march=pentium4m -O2 -fomit-frame-pointer -pipe -mmmx -msse -msse2 -mno-sse3 -mno-3dnow"
CXXFLAGS="${CFLAGS}"
Comment 17 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-08-02 00:18:23 UTC
Sorry but

a) I don't take care of ffmpeg myself directly;
b) x86 problems goes to x86 arch team, exactly as if it was VIS failing it'd be sent to SPARC team.
Comment 18 Martin von Gagern 2006-08-02 03:57:00 UTC
(In reply to comment #13)
> With a proposed fix here:
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/008506.html
> The proposed fix has very long discussion btw.

I don't think this is a proposed fix, I believe this is the patch that caused this bug in the first place.

From the discussion, perhaps this lead you to think it's a fix.
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/008613.html:
>> a minor issue, dont use ebx please, it causes PIC fanboys to flame us
>> and a major one REG_c is changed and not an output or cloberlisted
>> 
> ebx changed to REG_b. h_b (input to the function) has been changed from
> type int to type long so that this fix will work.

But REG_b is #defined to ebx, so this changes nothing.
Comment 19 Anders Storsveen 2006-08-02 04:28:51 UTC
do you guys use the -fPIC CFLAG? I was thinking it might be the problem, filtering it out has helped other packages
Comment 20 spiralvoice 2006-08-02 05:01:20 UTC
(In reply to comment #2)
> *** Bug 142385 has been marked as a duplicate of this bug. ***

In the above bug report I wrote:

> This is a known bug:
> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/31520
> Removing -fPIC reports to fix this problem, though I did not test that.
Comment 21 Christian Faulhammer (RETIRED) gentoo-dev 2006-08-02 05:51:47 UTC
I can confirm that -fPIC causes the error, emerge without it just runs fine.

Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gentoo-r4 i686)
=================================================================
System uname: 2.6.17-gentoo-r4 i686 AMD Athlon(tm) XP 2500+
Gentoo Base System version 1.6.15
app-admin/eselect-compiler: [Not Present]
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo"
CXXFLAGS="-O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/"
LANG="de_DE@euro"
LC_ALL="de_DE@euro"
LINGUAS="de"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.informatik.rwth-aachen.de/gentoo-portage"
USE="x86 3dnow 3dnowext X Xaw3d a52 alsa arts artworkextra asf audiofile avi bash-completion beagle berkdb bidi bitmap-fonts bootsplash branding bzip2 cairo cdda cddb cdparanoia cdr cli cracklib crypt css cups curl custom-cflags dbus dga directfb divx4linux dlloader dri dts dvd dvdr dvdread dvi eds emacs emboss encode esd evo exif expat fam fat fbcon fdftk ffmpeg firefox foomaticdb fortran ftp gb gcj gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml hal icq idn imagemagick imap imlib ipv6 isdnlog java javascript jikes jpeg jpeg2k ldap leim libg++ libwww lm_sensors mad maildir matroska mbox mikmod mime mmx mmxext mng mono motif mp3 mpeg mpeg2 mule nautilus ncurses nforce2 nls nocardbus nptl nptlonly nsplugin nvidia objc ogg opengl pam pcre pdf pdflib perl plotutils pmu png ppds pppd preview-latex print python qt qt3 qt4 quicktime readline reflection reiserfs samba sdk session slang spell spl sse ssl svg svga t1lib tcltk tcpd theora thunderbird tiff truetype truetype-fonts type1-fonts udev usb vcd videos vorbis win32codecs wmf wxwindows xine xml xorg xosd xv xvid zlib elibc_glibc input_devices_mouse input_devices_keyboard kernel_linux linguas_de userland_GNU video_cards_radeon video_cards_vesa video_cards_fbdev"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 22 Todd Merrill 2006-08-02 06:06:49 UTC
(In reply to comment #20)
> > This is a known bug:
> > http://article.gmane.org/gmane.comp.video.ffmpeg.devel/31520
> > Removing -fPIC reports to fix this problem, though I did not test that.

Commenting out the PIC-related lines from the ebuild fixed the problem for me.  Perhaps a pic USE flag for x86 (or all) users should be added?
Comment 23 Martin von Gagern 2006-08-02 13:07:54 UTC
Created attachment 93285 [details, diff]
Patch snowdsp_mmx.c to avoid or restore ebx

Since there is so much activity on this bug here, I tried to get this fixed. Don't know too much about video editing or inline assembly, but I think this might work.

I tried to use another register instead of ebx whenever possible. In cases where all 6 general purpose and index registers are used, I allocated a local variable and stored ebx there for the time being. Using a local variable avoids worrying about changing esp and makes sure all input arguments are still valid.

Maybe someone who knows what this piece of code is actually for could give it a try if it still does what you'd expect it to do?
Comment 24 Jakub Moc (RETIRED) gentoo-dev 2006-08-03 05:24:59 UTC
*** Bug 142641 has been marked as a duplicate of this bug. ***
Comment 25 Todd Merrill 2006-08-03 10:05:24 UTC
(In reply to comment #23)
> Created an attachment (id=93285) [edit]
> Patch snowdsp_mmx.c to avoid or restore ebx
> 
> Maybe someone who knows what this piece of code is actually for could give it a
> try if it still does what you'd expect it to do?

The patch applies, and ffmpeg now compiles and runs with -fPIC here.  Unfortunately, that's about all I can tell you.  I don't use ffmpeg often.  However, while reading up on the compile error, I stumbled upon something interesting.

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009613.html

"That looks like my code. If PIC support is very important to anyone
(whatever that is), they're free to write a patch that avoids the use of
ebx. Avoiding it is easy in vertical_compose, but it will likely be very
hard to avoid using in inner_add_yblock because every register gets
used, and I already had to make sacrifices to squeeze it in the existing
registers. A loss of speed in add_yblock is also inevitable if ebx is
not used (perhaps as little as a push and pop of ebx if you can use that
with GCC inline assmebly)."

I'm not a programmer, but your patch seems to do just that, i.e. not using the ebx registers.  Is there another way to do this?
Comment 26 Martin von Gagern 2006-08-03 11:43:11 UTC
(In reply to comment #25)
> I'm not a programmer, but your patch seems to do just that, i.e. not using the
> ebx registers.

Yes, I read that message as well. In some cases that's what I did, and in others I restored the old value of ebx so it isn't clobbered after the asm block.

> Is there another way to do this?

Probably yes:
1. Use push/pop - might break stack relative addressing of parameters ?
2. Use some register freed by -fomit-frame-pointer - don't know how, though
3. Rewrite asm code to use fewer registers - would require more understanding
4. Convince gcc to manage ebx - don't know how, as
   simply adding -fcall-saved-ebx to CFLAGS does not work.
5. Improve gcc to take care of ebx - should work unless parameters are
   ebx-relative, but to my knowledge it has not been implemented so far.

So there are likely to be other approaches to the problem, and I don't claim mine to be the best.

I submitted my patch to the ffmpeg-devel list, but as I'm not a list member it seems it has not been forwarded yet. Any ffmpeg-devel members here?

To get the thing included upstream it would likely need to be "#ifdef PIC"ed so that non-PIC code suffers no penalty at all. I'm waiting for someone to confirm that the code still works before doing further work in that direction. For Gentoo it should be enough to apply the patch to the shared source tree only.
Comment 27 Joshua Jackson (RETIRED) gentoo-dev 2006-08-03 12:10:48 UTC
(In reply to comment #26)
 For
> Gentoo it should be enough to apply the patch to the shared source tree only.
> 


Martin, thank you for the patch. From looking over it it should work. I'll have to test it later tonight before bumping up the version with permission from the video herd. Really, this is as much a hardened thing as a x86 specific one but *shrugs* as long as it gets fixed.
Comment 28 Wiktor Wandachowicz 2006-08-05 09:36:01 UTC
I've been hit by this bug as well (x86, gcc-4.1.1), but the patch from
comment #23 worked very well.

I've searched a bit and I've found that this is not the first time a package
suffers from similar problems, just to recap:
* Bug #73342 where xine-lib-1-rc7 gets a fix for clobbering %ebx
* Posts from mplayer developers (especially the second one), where problems
  regarding SSE optimizations are discussed:
  http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/008506.html
  http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009613.html
* Bug #86843 where interdependencies between USE=mmx, CFLAGS=-fPIC, -DPIC
  define and shortage of registers on x86 are discussed

Overall, it's been an interesting learning experience. And the patch from
comment #23:
  http://bugs.gentoo.org/attachment.cgi?id=93285&action=view
compared to the one from Bug #73342:
  http://bugs.gentoo.org/attachment.cgi?id=47148&action=view
really looks good.
Not to mention that it works, too :-)

I hope this will make its way to the portage eventually.
Comment 29 Jakub Moc (RETIRED) gentoo-dev 2006-08-05 11:11:40 UTC
*** Bug 142898 has been marked as a duplicate of this bug. ***
Comment 30 Christian Faulhammer (RETIRED) gentoo-dev 2006-08-06 14:33:59 UTC
*** Bug 143017 has been marked as a duplicate of this bug. ***
Comment 31 Jakub Moc (RETIRED) gentoo-dev 2006-08-06 23:45:53 UTC
*** Bug 143027 has been marked as a duplicate of this bug. ***
Comment 32 crusaderky 2006-08-07 06:19:57 UTC
identical problem here.

USE="a52 aac dts encode imlib mmx network ogg sdl theora threads truetype v4l vorbis xvid zlib -amr -debug -doc -ieee1394 -oss -test -x264"

CFLAGS="-Os -pipe -march=athlon-xp -fforce-addr -fomit-frame-pointer -falign-functions=4 -mfpmath=sse"
Comment 33 Aurélien Bauchet 2006-08-07 12:10:22 UTC
Same bug with this :

USE="acpi -apm aalib 3dnow 3dnowext mmx mmxext sse sse2 \
aac X gtk2 gnome wxwindows -qt -qt3 -qt4 -kde -arts dvd alsa cdr nptl \
nvidia cjk xinerama unicode matroska win32codecs real xvid ldap a52 ffmpeg hal theora ieee1394 dts \
-xmms -ipv6 firefox nsplugin \
bzip2 tiff lcms mng gtkhtml -apache2 hal dbus gphoto2"

CFLAGS="-march=athlon-xp -O3 -pipe -mmmx -m3dnow -msse -msse2 -fomit-frame-pointer -fforce-addr -ftracer"
Comment 34 Luca Barbato gentoo-dev 2006-08-07 13:47:09 UTC
I'm not ignoring you, I pushed the patch upstream and I'm working with the team to have the issue fixed.
Comment 35 Luca Barbato gentoo-dev 2006-08-07 14:32:19 UTC
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/34897

update: patch not correct.
Comment 36 Martin von Gagern 2006-08-07 15:00:56 UTC
Created attachment 93696 [details, diff]
patch mmx.h to use ebp instead of ebx as REG_b in PIC mode

(In reply to comment #35)
> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/34897
(from that message)
> if REG_b is not on the clobber list then you cannot clobber it, for example
> it might be used in a "m"  or a "r" 

This argument is valid in the general case. However, if you really do use PIC mode, then you could probably rely on ebx being used for the GOT and nothing else, and thus all operands being independent from ebx because they are not GOT-relative. But I agree there are quite some ifs and a lot of dependence on current behaviour that is likely to change in some future version.
So another, cleaner approach would be nice if any such is possible.

I attached another solution. This time I rely on -fomit-frame-pointer, which frees ebp to be used as a sixth register. So whoever wants to use -fPIX should specify -fomit-frame-pointer as well (as the Gentoo ebuild automatically does), and my patch should hopefully handle the rest. Sources compile cleanly.

I also did some basic tests to see if I could get gcc to allocate six registers by itself: http://gcc.gnu.org/bugzilla/attachment.cgi?id=12038
As you can see from the URL, things did not go as smoothly as I had hoped. Especially when combining this approach with no optimization or some other code, things did not work well. The details seem extremely bizarre to me and are documented at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28635

But with some optimization and only one asm statement per function, things seemed to work, so this might be another approach that could do without preprocessor magic.
Would require some major rewriting of existing asm code, though.
Comment 37 Ryan Hill (RETIRED) gentoo-dev 2006-08-07 22:51:04 UTC
We should really try to get away from relying on -fomit-frame-pointer to free up a register.
Comment 38 Martin von Gagern 2006-08-08 00:37:14 UTC
(In reply to comment #37)
> We should really try to get away from relying on -fomit-frame-pointer to free
> up a register.

Why? Do you have any idea how to achieve this? There seems to be quite a lot of code that uses six registers. If we really can't use ebx for -fPIC, omitting frame pointers seems the only viable approach to me, short of rewriting all this code to some less performant implementation with less registers.

Let me just look at this list I posted before...
(In reply to comment #26)
> 1. Use push/pop - might break stack relative addressing of parameters ?

I verified that especially with -fomit-frame-pointer, esp is really part of most local variable addresses. Even worse, this would clobber ebx in between as well, so it's no better than my patch from comment 23.

> 2. Use some register freed by -fomit-frame-pointer - don't know how, though

That's my new patch from comment 36, of course depending on this flag.

> 3. Rewrite asm code to use fewer registers - would require more understanding

The only viable solution I see for not relying on -fomit-frame-pointer and still using -fPIC. I fear it will have a performance impact.

> 4. Convince gcc to manage ebx - don't know how, as
>    simply adding -fcall-saved-ebx to CFLAGS does not work.

Still no idea here. I fear it might simply not be possible.

> 5. Improve gcc to take care of ebx - should work unless parameters are
>    ebx-relative, but to my knowledge it has not been implemented so far.

This still has some appeal to me, but it might prove extremely difficult. Basically gcc would take care of saving and restoring ebx as well as ensuring that no other parameter relies on ebx. But I fear even if we could get gcc to do this, it would not be an option for upstream, as it would make ffmpeg rely on a patched and/or very recent gcc, which probably is unacceptable there.

For those interested, http://gcc.gnu.org/viewcvs/trunk/gcc/stmt.c contains the code leading to this message in expand_asm_operands. It would need some way to notice if any of the operands uses ebx, and should only fail if this is the case as well as ebx being in the clobber list. Anyone here knows more about gcc?
Comment 39 Jakub Moc (RETIRED) gentoo-dev 2006-08-08 03:06:49 UTC
*** Bug 143187 has been marked as a duplicate of this bug. ***
Comment 40 Ilya Eremin 2006-08-08 06:50:02 UTC
It seems the other patch got rejected as well, may be just add a pic use flag and warn people that some things might break?
Comment 41 Luca Barbato gentoo-dev 2006-08-08 07:26:22 UTC
the proposed solution got reject, please make sure that it passes make test or it will be rejected by default.
Comment 42 Pierre Poissinger 2006-08-08 15:22:39 UTC
After 7 days, I start to think a temp fix should be applied ASAP aka: remove -fPIC for x86 until a patch get accepted upstream... 
Don't tell me it's bad... it's obviously not possible to compile this thing on x86 without a clean patch that don't exist yet (and it seems it won't be that easy to produce). Btw, plz, don't start to argue it's against some rules, on x86 it's a fake issue...

Comment 43 Mike Auty gentoo-dev 2006-08-08 15:26:39 UTC
Pierre, a simpler solution that can already be put in place by the users without having to modify the ebuild, it to turn off the mmx USE flag.  This can be done for ffmpeg only as follows:

Edit /etc/portage/package.use
Add a line that reads: media-video/ffmpeg -mmx

Once this bug is marked as fixed, you can simply remove the line from /etc/portage/package.use.  This should solve your problem immediately...  5:)
Comment 44 Alexander Skwar 2006-08-08 22:39:16 UTC
(In reply to comment #43)
> Pierre, a simpler solution that can already be put in place by the users
> without having to modify the ebuild, it to turn off the mmx USE flag.

Mike, the simplest solution for right now, would be to simply dump the mmx USE flag and then later re-add it, if a fix is found. I can't understand, why Gentoo knowingly ships something, which does not work. Beats me.
Comment 45 Joshua Jackson (RETIRED) gentoo-dev 2006-08-08 22:49:21 UTC
(In reply to comment #44)
> (In reply to comment #43)
> > Pierre, a simpler solution that can already be put in place by the users
> > without having to modify the ebuild, it to turn off the mmx USE flag.
> 
> Mike, the simplest solution for right now, would be to simply dump the mmx USE
> flag and then later re-add it, if a fix is found. I can't understand, why
> Gentoo knowingly ships something, which does not work. Beats me.
> 


This one got my ire up a bit, thanks kindly. I didn't run into this bug as I don't run mmx as a flag. Testing for ~arch, which is not the stable tree, I wouldn't of considered actually looking that closely. It worked for me without issue. However, we have lots of users who run with mmx in their use flags..that's a choice that I didn't make.

Saying that we shipped it knowing it was broken is stepping over the bounds and I'm quite disappointed in your response because of it. It does work, it just isn't perfect. Thats different from what you say is just plain broken. We have a place for things that are entirely broken and its called package.mask. ~arch is not stable. So please don't expect it to always work.

I'm seriously going to have to start a campaign that ~arch isn't stable. Use it at your own risk.

Tsunam, the one one who did the ~arch commit, has tested this  with issues and has personally looked into ways of fixing it, but nope..doesn't matter as its just plain broken entirely *nods*. Thanks for making me love the people I consider peers that much more!


Comment 46 Jakub Moc (RETIRED) gentoo-dev 2006-08-08 23:10:41 UTC
*** Bug 143281 has been marked as a duplicate of this bug. ***
Comment 47 Piotr Szymaniak 2006-08-08 23:31:30 UTC
(In reply to comment #16)
> Same problem here & works fine without the MMX flag set.

Same here.
Comment 48 Alexander Skwar 2006-08-08 23:59:14 UTC
(In reply to comment #45)
> (In reply to comment #44)

> > Mike, the simplest solution for right now, would be to simply dump the mmx USE
> > flag and then later re-add it, if a fix is found. I can't understand, why
> > Gentoo knowingly ships something, which does not work. Beats me.
> > 
> 
> 
> This one got my ire up a bit, thanks kindly. I didn't run into this bug as I
> don't run mmx as a flag.

Fine. Not much of a problem.

> Testing for ~arch, which is not the stable tree, I
> wouldn't of considered actually looking that closely.

Fine.

> It worked for me without
> issue. 

As you don't have mmx in your USE flags.

> However, we have lots of users who run with mmx in their use
> flags..that's a choice that I didn't make.

Fine.

> Saying that we shipped it knowing it was broken is stepping over the bounds and
> I'm quite disappointed

I'm also quite disappointed by Gentoo still offering this version with MMX support. Why not simply release a -r1, where MMX flag is not supported?

> in your response because of it. It does work, it just
> isn't perfect.

Where does the current version work on x86 (ie. the x86 hardware, not the x86 arch in Gentoo speak) with MMX?

> Thats different from what you say is just plain broken.

Where did I say, that it's *plain* broken (or "entirely", as you later say)?

> We have
> a place for things that are entirely broken and its called package.mask. ~arch
> is not stable. So please don't expect it to always work.

I don't. But I don't expect it to KNOWLINGY for a rather long period of time to NOT work, which is the current state of ffmpeg with regards to MMX support or the mmx USE flag.

> Tsunam, the one one who did the ~arch commit, has tested this  with issues and
> has personally looked into ways of fixing it, but nope..doesn't matter as its
> just plain broken entirely

I did not say, that it's entirely broken. I said, that the MMX flag should be dropped, as this is broken - else, there wouldn't be this bug, would there? I further said, that the mmx flag should be re-added, as soon as MMX is working again. 
Comment 49 David Li 2006-08-09 04:54:38 UTC
Hey guys. Please keep the arguments down on the bugzilla. That's what the mailing lists are for.

Anyways, if you drop the useflag, a revbump should not be nessary because that's what newuse is for (and the new portage version will pick it up as well).
Comment 50 Horst Schirmeier 2006-08-09 05:17:00 UTC
Calm down, ladies. Which part of "unstable" is it you don't understand?
Comment 51 Martin von Gagern 2006-08-09 10:24:31 UTC
(In reply to comment #41)
> the proposed solution got reject, please make sure that it passes make test or
> it will be rejected by default.

OK, I finally subscribed to the mailing lists, and got myself a svn checkout so I'm working on a clean source tree and have all those tests at hand. I'm also finally sitting in front of the machine I'm testing things on, and I'm heading for a major rewrite. I'll take my patches upstream myself from now on.

I just got somewhat confused from these lines in the ebuild:
>	#disable mmx accelerated code if not requested, or if PIC is required
>	# as the provided asm decidedly is not PIC.
>	if ( gcc-specs-pie || ! use mmx ) && ( ! use amd64 ); then
>		myconf="${myconf} --disable-mmx"
>	fi
I take it they are talking about PIE, because PIC libraries did work in previous versions afaik.
Comment 52 Pierre Poissinger 2006-08-09 14:15:28 UTC
Created attachment 93868 [details, diff]
ebuild patch to remove PIC for the special case of MMX+x86 

Ok, my previous post was not intended to generate so much noise... I won't feed the troll even if I really want to... Just to make things clear: It was not an remark against devs... just against some "politics" issue... 

I include an unholy patch to the ebuild to AT LEAST compile this package WITH MMX [This has performance inpact] and without PIC (on x86 only... where position indep. code has the advantage to not be usefull)

Cheers,
Comment 53 Rickard Närström 2006-08-09 15:02:49 UTC
(In reply to comment #52)
> Created an attachment (id=93868) [edit]
> ebuild patch to remove PIC for the special case of MMX+x86 

This will not work on amd64, libraries have to be PIC on amd64 to link.

But anyway we have more registers on amd64 so we only need to pick a free register to use.
Comment 54 Joshua Jackson (RETIRED) gentoo-dev 2006-08-09 15:08:32 UTC
(In reply to comment #52)
> Created an attachment (id=93868) [edit]
> ebuild patch to remove PIC for the special case of MMX+x86 
> 
> Ok, my previous post was not intended to generate so much noise... I won't feed
> the troll even if I really want to... Just to make things clear: It was not an
> remark against devs... just against some "politics" issue... 
> 
> I include an unholy patch to the ebuild to AT LEAST compile this package WITH
> MMX [This has performance inpact] and without PIC (on x86 only... where
> position indep. code has the advantage to not be usefull)
> 
> Cheers,
> 

This kills hardened support for the package, and althought it'd fix it, its not ideal either. We are working on the issue, and attempting to get a proper fix that doesn't affect anyone negatively. For now the fix is either to not run the 530 build, as other versions work with mmx and pic, or remove mmx from this one ebuild. 
Comment 55 Rickard Närström 2006-08-09 15:09:53 UTC
(In reply to comment #53)
> (In reply to comment #52)
> > Created an attachment (id=93868) [edit]
> > ebuild patch to remove PIC for the special case of MMX+x86 
> 
> This will not work on amd64, libraries have to be PIC on amd64 to link.
> 
> But anyway we have more registers on amd64 so we only need to pick a free
> register to use.
> 

Sorry, it is working on amd64 as it is now....
Comment 56 Pierre Poissinger 2006-08-10 00:36:56 UTC
I guess the line 
"if [[ $(tc-arch) == "x86" ]]; then" in the patch I sended should avoid to apply it on amd64 no ? 

Anyway, I posted the patch since it's the way I used to fix the prob on my side, for the people who still want to keep MMX :-) 
Comment 57 Martin von Gagern 2006-08-10 09:18:11 UTC
Created attachment 93918 [details, diff]
Patch to snowdsp_mmx.c

This patch has been accepted and included upstream:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-August/013818.html

I just checked that an ebuild applying this patch compiles on my system.

I would like to see an ebuild applying this patch or using a recent snapshot in portage asap, as the number of cc list members indicates a lot of interest.
Comment 58 Luca Barbato gentoo-dev 2006-08-10 09:43:26 UTC
I'd rather wait for a day till the vorbis optimization are checked in.
Comment 59 Christian Faulhammer (RETIRED) gentoo-dev 2006-08-14 02:35:44 UTC
*** Bug 143864 has been marked as a duplicate of this bug. ***
Comment 60 Antony Mee 2006-08-14 03:30:36 UTC
Created attachment 94217 [details]
Ebuild with patch for snowdsp_mmx

While Luca is for the Vorbis optimizations to be checked in... 

To save anbody else having to to this make this just to get their update to finish cleanly: Here is a complete ebuild ready to be untared in the root of your favourite overlay (it includes the media-video/ffmpeg/ tree).

This '-r1' version will no doubt clash with Luca's next update so be warned
Be prepared to delete it from your overlay and force ffmpeg to update (emerge -av --oneshot ffmpeg) to get Luca's real '-r1' version.
Comment 61 Martin von Gagern 2006-08-14 05:10:28 UTC
(In reply to comment #60)

Nice thing, but there are minor issues to remember for the future.

> Ebuild with patch for snowdsp_mmx

I'd not call this an ebuild, as it is a tar archive containing additional files as well. Seeing an attachmend called ebuild, I'd expect just a single text/plain file, the ebuild itself.

> This '-r1' version will no doubt clash with Luca's next update so be warned
> Be prepared to delete it from your overlay and force ffmpeg to update (emerge
> -av --oneshot ffmpeg) to get Luca's real '-r1' version.

I don't think it will clash. I guess the p2006... part of the version is in fact the CVS snapshot date, so that the next version will probably be based on an altogether new snapshot.

Still, why did you name your ebuild -r1? The issue is a compile time issue, so people either had things working (because of no mmx or some such) or are still stuck with some older version. OK, they might have an entry in their package.use that says "=media-video/ffmpeg-0.4.9_p20060530 -mmx", but people who explicitly download your overlay fragment will manage to remove this setting and remerge the package as well, especially as you already gave the command for this.

My point is: in my understanding revisions are for automatic updates leading to improvements to the runtime behaviour. Compile time issues should not need revision bumps, and ebuilds from your private overlay neither.
I'd just call this ffmpeg-0.4.9_p20060530, and let the overlay take precedence over the main portage tree as it does by default.
Comment 62 Luca Barbato gentoo-dev 2006-08-14 06:02:44 UTC
Martin since ffmpeg is going to depend on an x264 version that's too new for other software (and I learned that the hard way) I'll commit your patch in a ffmpeg bug and I'll add the new snapshot in p.mask .

Thank you for your contribution =)
Comment 63 Luca Barbato gentoo-dev 2006-08-14 06:04:11 UTC
Comment on attachment 94217 [details]
Ebuild with patch for snowdsp_mmx

Ops. I didn't notice it was a compressed file, please, next time attach just the ebuild
Comment 64 Luca Barbato gentoo-dev 2006-08-14 06:37:43 UTC
ebuild updated, wait an hour and then try to emerge it
Comment 65 Dominik Strehlke 2006-08-14 16:03:50 UTC
Now it works here, same setup. Thanks for your great work!
Comment 66 Joshua Jackson (RETIRED) gentoo-dev 2006-08-14 20:32:25 UTC
closing as fixed as well now