build.log fragment: libavcodec/ppc/fft_altivec_s.S: Assembler messages: libavcodec/ppc/fft_altivec_s.S:447: Error: junk at end of line, first unrecognized character is `@' libavcodec/ppc/fft_altivec_s.S:448: Error: junk at end of line, first unrecognized character is `@' make: *** [libavcodec/ppc/fft_altivec_s.o] Error 1 make: *** Waiting for unfinished jobs.... Reproducible: Always Steps to Reproduce: 1. emerge --sync -q 2. emerge -quDN world Actual Results: Emerge reports that it failed to emerge the package. Expected Results: Emerge should have built and installed the package. Building on ppc with altivec enabled.
Created attachment 250819 [details] ebuild log -- /var/tmp/portage/media-video/ffmpeg-0.6_p25423/temp/build.log
Maybe related to bug 340539 ?
Created attachment 250821 [details] output from emerge --info
Created attachment 250823 [details] /etc/make.conf
Created attachment 250825 [details] faulty assembler file referred-to in build.log
Hm you have CHOST powerpc but you are running a ppc64 system. This, the binutils version (the other one uses 2.18) and that it uses latest SNV of FFmpeg (which should not matter here) are the only relevant differences I can see between you system and the on that is continuously tested: http://fate.ffmpeg.org/powerpc64-linux-gcc-4.3.5/20101016214933
(In reply to comment #6) > Hm you have CHOST powerpc but you are running a ppc64 system. > This, the binutils version (the other one uses 2.18) and that it uses latest > SNV of FFmpeg (which should not matter here) are the only relevant differences > I can see between you system and the on that is continuously tested: > http://fate.ffmpeg.org/powerpc64-linux-gcc-4.3.5/20101016214933 I'm not clear about whether your comment is just a note-to-file or musing as it were, or a statement of what is causing the problem. My system is a 64 bit kernel with 32 bit userland and I've not changed CHOST from what was initially installed. Do you need further information from me, or should I be changing some settings, e.g., masking some subsidiary packages ?
Hey I have the same problem here. libavcodec/ppc/fft_altivec_s.S:447: Error: junk at end of line, first unrecognized character is `@' libavcodec/ppc/fft_altivec_s.S:448: Error: junk at end of line, first unrecognized character is `@' Portage 2.1.9.24 (default/linux/powerpc/ppc64/10.0/32bit-userland, gcc-4.4.5, glibc-2.12.1-r3, 2.6.32-gentoo-r7 ppc64) ================================================================= System uname: Linux-2.6.32-gentoo-r7-ppc64-PPC970FX,_altivec_supported-with-gentoo-2.0.1
This assembly file is newly introduced after ffmpeg-0.6 http://git.ffmpeg.org/?p=ffmpeg;a=history;f=libavcodec/ppc/fft_altivec_s.S;h=5d3c5406c3186abe4fa0a1edaf8add8af0fb6022;hb=HEAD It seems that tweaking is needed. I am not familiar with assembly though.
Please find out what is special about your systems, at the very least post your binutils versions. As you can see here: http://fate.ffmpeg.org FFmpeg compiles and runs just fine on multiple PPC Gentoo systems.
The only thing I can think-of that is special about my system is that it is built with ACCEPT_KEYWORDS=~ppc. I deliberately avoid doing anything else non-standard or destabilising; for example, I don't use any overlays. binutils version is 2.20.1-r1. Please, if you need further information, ask ASAP because I have stopped using the machine and will be selling it soon.
> binutils version is 2.20.1-r1. It's 2.18 on the ppc64 machine the tests run. Maybe someone can test if they have the issue with that version (or in general "stable" binutils) or if it goes away. (I don't have root on the test machine so it would be a pain to test 2.20 myself)
> It's 2.18 on the ppc64 machine the tests run. > Maybe someone can test if they have the issue with that version (or in general > "stable" binutils) or if it goes away. (I don't have root on the test machine > so it would be a pain to test 2.20 myself) I downgraded binutils to 2.18-r4. ffmpeg still does not build. There are several build messages of the form: /var/tmp/portage/media-video/ffmpeg-0.6_p25423/temp/something.s: nnn: Error: unknown pseudo-op `.cfi_sections´
I encontered the same problem. On ps3. ps3~ # emerge --info =media-video/ffmpeg-0.6_p25767 Portage 2.1.9.25 (default/linux/powerpc/ppc64/10.0/32bit-userland, gcc-4.3.4, glibc-2.10.1-r1, 2.6.32-gentoo-r7 ppc64) ================================================================= System Settings ================================================================= System uname: Linux-2.6.32-gentoo-r7-ppc64-Cell_Broadband_Engine,_altivec_supported-with-gentoo-1.12.13 Timestamp of tree: Mon, 27 Dec 2010 00:15:01 +0000 distcc 3.1 powerpc-unknown-linux-gnu [disabled] app-shells/bash: 4.0_p37 dev-lang/python: 2.4.4-r13, 2.6.5-r2, 3.1.2-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.65 sys-devel/automake: 1.6.3-r1, 1.8.5-r4, 1.10.1, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b sys-devel/make: 3.81 virtual/os-headers: 2.6.30-r1 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="ppc" ACCEPT_LICENSE="* -@EULA" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -pipe -mcpu=cell -mabi=altivec" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -mcpu=cell -mabi=altivec" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirrors.xmu.edu.cn/gentoo ftp://mirrors.xmu.edu.cn/portage" LC_ALL="zh_CN.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="zh_CN zh en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/portage" SYNC="rsync://mirrors.xmu.edu.cn/gentoo-portage" USE="X acl alsa altivec berkdb bzip2 cblas cjk cli cracklib crypt cxx dbus dri encode ffmpeg flac fortran gcc64 gdbm gpm gsl gtk hal iconv ipv6 jpeg jpeg2k modules mpeg mplayer mudflap ncurses nls nptl nptlonly openmp oss pam pcre perl ppc pppd ps3 python readline sdl session ssl subversion symlink sysfs tcpd threads tiff truetype unicode usb vim-syntax wifi xorg zlib" ALSA_CARDS="aoa aoa-fabric-layout aoa-onyx aoa-soundbus aoa-soundbus-i2s aoa-tas aoa-toonie powermac usb-audio via82xx" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev mouse keyboard joystick" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="zh_CN zh en" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ps3~ # ps3 ~ # emerge -pqv =media-video/ffmpeg-0.6_p25767 [ebuild N ] media-video/ffmpeg-0.6_p25767 USE="X alsa altivec bzip2 encode hardcoded-tables jpeg2k oss sdl threads zlib (-3dnow) (-3dnowext) -amr -bindist (-cpudetection) -custom-cflags -debug -dirac -doc -faac -frei0r -gsm -ieee1394 -jack (-mmx) (-mmxext) -mp3 -network -pic -qt-faststart -rtmp (-schroedinger) -speex (-ssse3) -static-libs -test -theora -v4l -v4l2 (-vaapi) -vdpau -vorbis (-vpx) (-x264) -xvid" VIDEO_CARDS="(-nvidia)" ps3 ~ #
Created attachment 258169 [details] ffmpeg-0.6_p25767 build log ffmpeg-0.6_p25767 build log
Same here on ppc64with 32bitul on both ffmpeg and mplayer-embedded version.
# as --version GNU assembler (GNU Binutils) 2.21
I can confirm the issue is nothing to do with binutils but the use of 32-bit userland on a 64-bit kernel (common, if not recommended, on ppc). ffmpeg's configure uses a bare $(uname -m) to determine arch if not set using --arch. As such, it picks up ppc64 on these systems and defines ARCH_PPC64, which later causes the assembly build to fail. This is because libavcodec/ppc/asm.S defines the instructions differently if ARCH_PPC64 is set: #if ARCH_PPC64 #define PTR .quad #define lp ld #define lpx ldx #define stp std #define stpu stdu #define PS 8 #define L(s) JOIN(., s) .macro extfunc name .global X(\name) .section .opd, "aw" X(\name): .quad L(\name), .TOC.@tocbase, 0 .previous .type X(\name), STT_FUNC L(\name): .endm .macro movrel rd, sym ld \rd, \sym@got(r2) .endm The fix is to explicitly pass --arch on ppc in the ebuild: if [[ $(tc-arch) == "ppc" ]]; then myconf="${myconf} --arch=$(tc-arch)" fi This won't affect pure 32-bit ppc (as uname -m already returns 'ppc') but will fix the case where uname -m returns ppc64 but tc-arch is ppc.
I sent a patch to autodetect 32 vs. 64 bit as already done on x86: http://ffmpeg.org/pipermail/ffmpeg-devel/2011-August/114326.html Testing is welcome, and it should be quite simple to backport this to old FFmpeg versions.
Thanks. Note that mplayer suffers from the same issue as it includes an in-tree copy of ffmpeg.
(In reply to comment #19) > I sent a patch to autodetect 32 vs. 64 bit as already done on x86: > http://ffmpeg.org/pipermail/ffmpeg-devel/2011-August/114326.html > Testing is welcome, and it should be quite simple to backport this to old > FFmpeg versions. The patch works fine with me,now it runs great.:-)
should have been fixed long ago
