Bugzilla Bug 113255

....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 an attachment (id=75916) [details]
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.