....and so doesn't merge with FEATURES=stricter, or run on hardened systems. [ebuild N ] media-libs/xine-lib-1.1.1-r1 +X -a52 -aac -aalib +alsa (-altivec) -arts -asf -cle266 -debug -directfb -dts -dvd -dxr3 -esd -fbcon -ffmpeg +flac +gnome -i8x0 -imagemagick -ipv6 -libcaca -mad -mng +nls -nvidia -opengl -oss -samba -sdl -speex -theora -v4l -vcd -vidix -vorbis -win32codecs -xinerama -xv -xvmc 0 kB TEXTREL usr/lib/xine/plugins/1.1.1/xineplug_decode_ff.so TEXTREL usr/lib/xine/plugins/1.1.1/xineplug_decode_w32dll.so TEXTREL usr/lib/xine/plugins/1.1.1/xineplug_decode_qt.so TEXTREL usr/lib/xine/plugins/1.1.1/post/xineplug_post_planar.so TEXTREL usr/lib/xine/plugins/1.1.1/post/xineplug_post_tvtime.so !!! ERROR: media-libs/xine-lib-1.1.1 failed. !!! Function dyn_install, Line 1088, Exitcode 0 !!! Aborting due to textrels Portage 2.0.53_rc7 (selinux/2004.1/x86/hardened, gcc-3.4.4, glibc-2.3.5-r2, 2.6.13-hardened i686) ================================================================= System uname: 2.6.13-hardened i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.12.0_pre5 dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.13 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.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -fforce-addr -mno-tls-direct-seg-refs" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -fforce-addr -mno-tls-direct-seg-refs" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox selinux sesandbox severe sfperms strict stricter userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa bash-completion berkdb bitmap-fonts boundschecking bzip2 crypt dlloader erandom flac gnome gtk gtk2 hardened imap jpeg moznocompose moznoirc moznomail moznoxft multislot multitarget ncurses nls nptl nptlonly offensive ogg oggvorbis pam perl pic png python readline selinux ssl svg userlocales x86 zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS
x86 herd this is mainly your problem as it does not use textrels on amd64 (and I don't really know how to fix them). So if someone can take a look to the code and suggest some patch, it's welcome (w32dll support might not be fixable, as it needs to mime Windows calling conventions, but I have a patch to finally disable it if not requested).
http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml
Okay, I started looking deeper into them: TEXTREL usr/lib/xine/plugins/1.1.1/xineplug_decode_w32dll.so TEXTREL usr/lib/xine/plugins/1.1.1/xineplug_decode_qt.so The problem lies inside wine's code that's shared with mplayer. I'm not sure how much we can do with that as it requires to use Windows's calling conventions that might not be TEXTREL safe. I don't know enough about this, as it's hard x86 asm used to wrap around Win32 calls. I'm going to update soon xine-lib to actually disable win32codecs when not requested, so the solution to them can be masking win32codecs useflag in hardened profile. TEXTREL usr/lib/xine/plugins/1.1.1/xineplug_decode_ff.so TEXTREL usr/lib/xine/plugins/1.1.1/post/xineplug_post_planar.so These two are due to libavcodec/ffmpeg. I can't do much for them myself, the list of TEXTRELs is very very long, and I don't dare starting looking at the actual code. Also they should be fixed in ffmpeg before any fix can be done within xine-lib. TEXTREL usr/lib/xine/plugins/1.1.1/post/xineplug_post_tvtime.so This is code took from kdetv afaics, I'm not sure how to handle it tho, as it's deep deep asm code itself. So, if someone can fix the issues with ffmpeg, I can fix xine-lib's plugins for ffmpeg. The win32codecs thingy is up to the hardened devs, a fix is welcome if it exists, it would probably also be required in vlc and mplayer as they use the same code.
*** Bug 117255 has been marked as a duplicate of this bug. ***
As said, win32codecs is non-hardened-safe. Nothing can be done for that. The ffmpeg part is still to play with lu_zero/upstream...
Created attachment 75916 [details, diff] PIC/textrel fix for xine-lib who said 'nothing can be done'? ;-) more seriously, the attached patch fixes these: 1. textrels in the wine loader and tomsmocomp 2. lack of GNU-stack markings also, the ebuild has a typo: I810XvmC -> I810XvMC
Thanks, will send a note to upstream and tomorrow I'll start testing it (not today, as I took a day off :P) for inclusion later this week.
*** Bug 117714 has been marked as a duplicate of this bug. ***
Okay the xine-lib part is fixed, thanks to PaX Team. ffmpeg waits for ffmpeg to be patched before.
This is the reply from upstream developer Miguel Freitas: > this is a big asm patch, it's difficult to review and i'm almost sure > it will break compilation for gcc < 3 (it doesn't accept more than ten > asm parameters, see SearchLoopTop.inc part of the patch). > > the only chance to get this included is to have somebody to at least > check if everything still works (win32 dlls, qt dll, greedy2frame, > greedyh and tomsmocomp). even though i'm
This is the reply from upstream developer Miguel Freitas: > this is a big asm patch, it's difficult to review and i'm almost sure > it will break compilation for gcc < 3 (it doesn't accept more than ten > asm parameters, see SearchLoopTop.inc part of the patch). > > the only chance to get this included is to have somebody to at least > check if everything still works (win32 dlls, qt dll, greedy2frame, > greedyh and tomsmocomp). even though i'm not sure we should apply the > patch (and break gcc < 3) or leave it for hardned distro packagers... > > Miguel I'm not going to remove the patch as of now, but at the first report I get that this patch creates problem, it will go away. If somebody can fix it so that gcc < 3 is not stopped to work, so that the patch can be sent upstream again, then it would be better. In the mean time I'll consider it "experimental unstable code"..
If I recall this code can not be backported to the 5+ year old compiler gcc-2.95 (that nobody should really be trying to support) as it eats up even 1 more register. The only solution is probably to wrap the asm bits with a bunch of #ifdef
(In reply to comment #10) > I'm not going to remove the patch as of now, but at the first report I get that > this patch creates problem, it will go away. i hope you didn't mean that seriously and will instead let me know about any such troubles ;-). > If somebody can fix it so that gcc < 3 is not stopped to work, so that the > patch can be sent upstream again, then it would be better. > In the mean time I'll consider it "experimental unstable code".. it's a pity that upstream didn't really look at the code, i don't see how supporting 2.95 would help in that regard, the size of the patch would be even bigger, not smaller, and certainly more complex as well. anyway, i might look at it later, but it's not high priority.
Err I shouldn't have reopened this anyway. I'll try to poke upstream again anyway later on.
