Due to my own experiences with this application, I suggest: If (the platform is PPC and) "hardened" is in $USE, the ebuild should change the system's compiler to a -vanilla profile before building mplayer. The ebuild filters certain CFLAGS, and in most cases simply resets CFLAGS to "" (empty), and beyond that mplayer's configuration seems to do much the same, even if USE="custom-cflags", so things like "-fno-stack-protector -fno-pie" don't matter. If mplayer is built on a hardened system using the default settings, it (at least in my experience) barely runs, but not in a way that I would call acceptable. Video is low-quality, showing many blocks and compression artifacts, and audio stutters and lags. Compiling it with a -vanilla profile gives me a reasonable version of mplayer. For the record: Gentoo Base System version 1.6.14 Portage 2.0.54 (hardened/ppc, gcc-3.4.4, glibc-2.3.5-r3, 2.6.11-hardened-r15 ppc) ================================================================= System uname: 2.6.11-hardened-r15 ppc 7400, altivec supported distcc 2.18.3 powerpc-unknown-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.12 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-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="ppc" AUTOCLEAN="yes" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -mcpu=G4 -pipe -maltivec -mabi=altivec -mpowerpc-gfxopt" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/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="-O2 -mcpu=G4 -pipe -maltivec -mabi=altivec -mpowerpc-gfxopt" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sfperms strict" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp://gentoo.mirrors.tds.net/gentoo http://gentoo.mirrors.tds.net/gentoo ftp://gentoo.ccccom.com" MAKEOPTS="-j3" PKGDIR="/usr/portage//packages/ppc/" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X acl aim alsa altivec arts audiofile berkdb bzip2 bzlib cdr crypt cups curl dlloader dvdr effects ethereal exif expat fam fbcon ffmpeg flac foomaticdb gdbm gif gimp glibc-omitfp glut gmp gpm gstreamer gtk gtk2 gtkhtml hardened icq idn imagemagick imlib jabber java javascript jbig jikes joystick jpeg jpeg2k kde kdexdeltas lcms ldap libwww lzo lzw-tiff mad maildir matroska mng mozsvg mpeg mplayer musepack musicbrainz ncurses nsplugin ogg oggvorbis opengl oss pam parse-clocks pcre perl pic pie png ppc ppds profile python qt quicktime rage128 readline rtc sasl scanner sdl smp speex spell sqlite ssl svg sysfs tcpd tetex tiff truetype ucs2 udev unicode usb userlocales vcd vorbis wmf x264 xine xml2 xosd xv xvid yahoo zlib video_cards_ati128 userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
(In reply to comment #0) > If (the platform is PPC and) "hardened" is in $USE, the ebuild should change > the system's compiler to a -vanilla profile before building mplayer. Never... We can die in ebuild asking you to do it if there's absolutely no other solution, but mplayer ebuild won't be switching gcc specs to vanilla.
That's fair. :) I do think there ought to be *some* information for the user in the ebuild, about how they might get a more usable mplayer. (With the 1.0_pre releases, I had to compile them with GCC 3.3 for them to be stable, so this is progress!) What that information should be, though, I'm not quite sure of, since compiler and CFLAGS may have a large effect.
If you could narrow down what option exactly makes you drop frames that would be helpful. Clearly the ebuild needs to be patched with some logic to flip on the appropriate flags when necessary for a given arch.
if you have something concrete i can test it on this machine, we could get that into portage fairly easily since we have a hardened ppc box that is not headless to test this on.
Right now, the only concrete fact I can give you is that using gcc 3.4.4-vanilla works, and the "normal" one doesn't. However, in the next few days I'll be glad to do some test builds, by hand if necessary, to see if I can get a handle on it.
Well here are the two thungs that I think will help the most to narrow it down. try an append-flags -fno-pie ; append-flags -fno-stack-protector; chances are it's more the ssp than the pie that is causing the frame dropping. But I could be wrong and welcome any testing you two can do on ppc.
Update: I *am* working on testing this, but it's going to take more time than I thought. "append-flags" command has no effect, nor does altering CFLAGS directly, inside or outside the ebuild (even right before "make" is run). My "appended" flags are not used during the build, and I have been unable to produce a binary that actually runs! (This is a step backwards, since the other ones I made ran, but poorly.) More time shall pass while I figure out how to do this. I think I'm going to have to patch "config.mak" *after* configure is run.
added a append-flags -fno-stack-protector and it takes it just fine, i am using it with USE=custom-flags to avoid the ebuild unsetting CFLAGS and allowing mplayer to do its magic deterministic ways just search the ebuild for the custom-cflags if/else construct and insert your append-flags beteween the construct and the CFLAGS="${CFLAGS}..." line it still builds, plus i need to do some texting with and without to get an idea about frame dropping hope this helps
Ok, since this seems to be getting nowhere, here's what I have done. Enabled custom-cflags for mplayer in /etc/portage/package.use. Ebuild in /usr/local/portage edited to include: ... else unset CFLAGS CXXFLAGS fi # Next line for testing! Try one or both of no-stack-protector, no-pie einfo "append-flags is here!" append-flags -fno-stack-protector CFLAGS="$CFLAGS" ./configure \ ... ebuild /usr/local/portage/media-video/mplayer/mplayer-1.0.20060102.ebuild digest script mplayer-build-4 # capture the entire emerge session for examination FEATURES="-sandbox -userpriv -usersandbox" emerge -v mplayer # If I don't use those FEATURES I see "permission denied" errors while # configuring, and disturbing statements like # "Checking for cross compilation ... yes" !!! rm /usr/share/mplayer/codecs.conf exit Now, genlop claims that "-fno-stack-protector" was in use during the build, which means that it was in CFLAGS as expected. However, examining the captured session shows that this flag is never used. Example: cc -c -I../libvo -I../../libvo -I/usr/X11R6/include -W -Wall -Wno-unused-parameter -O2 -mcpu=7400 -mtune=7400 -maltivec -mabi=altivec -g -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I.. -I../osdep -I../libavutil -I/usr/include/freetype2 -I/usr/include/SDL -D_REENTRANT -I/usr/X11R6/include -DMPG12PLAY -o vo_png.o vo_png.c Attempting to run the mplayer just installed results in: mplayer: error while loading shared libraries: R_PPC_REL24 relocation at 0x154ff4f4 for symbol `getenv' out of range I'm going to see if I can get it to build manually. Meanwhile, any suggestions, or other info I can provide? Ideas about what's going on with portage here that my CFLAGS are swallowed?
*** This bug has been marked as a duplicate of bug 93862 ***
