Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 93862 - media-video/mplayer hardened support
Summary: media-video/mplayer hardened support
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: High major with 1 vote (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords:
: 78613 104004 122524 133586 175627 184003 246434 254494 256909 269103 291314 297787 324693 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-05-24 16:03 UTC by Attila Stehr
Modified: 2011-06-19 21:53 UTC (History)
26 users (show)

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


Attachments
patch 1/2: remove all mmx related cpu features on hardened (mplayer-1.0_rc2_p20090322.ebuild.patch,1.45 KB, patch)
2009-04-13 05:34 UTC, Hugo Mildenberger
Details | Diff
patch 2/2: make inclusion of mmx/sse related assembly routines dependand on config (mplayer-hardened-1.0_rc2_p20090322.patch,2.10 KB, patch)
2009-04-13 05:40 UTC, Hugo Mildenberger
Details | Diff
A ("workaround"?) pach (mplayer-hardened.patch,678 bytes, patch)
2010-03-02 08:26 UTC, Xake
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Attila Stehr 2005-05-24 16:03:24 UTC
mplayer can't be emerged.
Output of emerge states some warnings and this error:
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld:
libvo/libvo.a(osd.o): relocation R_X86 _64_32S against `a local symbol' can not
be used when making a shared object; recompile with -fPIC
libvo/libvo.a: could not read symbols: Bad value

Reproducible: Always
Steps to Reproduce:
1. emerge -v --deep --newuse mplayer


Actual Results:  
cc -c -I../libvo -I../../libvo -I/usr/X11R6/include  -march=athlon64 -pipe -O2
-frename-registers -D_REENTRANT -D_LAR GEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib6
4/glib/include -I. -I.. -I../libmpcodecs -I/usr/include/gtk-1.2
-I/usr/include/glib-1.2 -I/usr/lib64/glib/include -Wa ll
-I/usr/include/freetype2 -o menu_param.o menu_param.c
menu_param.c: In function `parse_args':
menu_param.c:83: Warnung: Dereferenzierung eines Type-Pun-Zeigers verletzt
strict-aliasing-Regeln
menu_param.c:93: Warnung: Dereferenzierung eines Type-Pun-Zeigers verletzt
strict-aliasing-Regeln
menu_param.c:56: Warnung: Variable 
Comment 1 Attila Stehr 2005-05-24 16:03:24 UTC
mplayer can't be emerged.
Output of emerge states some warnings and this error:
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld:
libvo/libvo.a(osd.o): relocation R_X86 _64_32S against `a local symbol' can not
be used when making a shared object; recompile with -fPIC
libvo/libvo.a: could not read symbols: Bad value

Reproducible: Always
Steps to Reproduce:
1. emerge -v --deep --newuse mplayer


Actual Results:  
cc -c -I../libvo -I../../libvo -I/usr/X11R6/include  -march=athlon64 -pipe -O2
-frename-registers -D_REENTRANT -D_LAR GEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib6
4/glib/include -I. -I.. -I../libmpcodecs -I/usr/include/gtk-1.2
-I/usr/include/glib-1.2 -I/usr/lib64/glib/include -Wa ll
-I/usr/include/freetype2 -o menu_param.o menu_param.c
menu_param.c: In function `parse_args':
menu_param.c:83: Warnung: Dereferenzierung eines Type-Pun-Zeigers verletzt
strict-aliasing-Regeln
menu_param.c:93: Warnung: Dereferenzierung eines Type-Pun-Zeigers verletzt
strict-aliasing-Regeln
menu_param.c:56: Warnung: Variable »ok« wird nicht verwendet
menu_param.c:56: Warnung: Variable »cancel« wird nicht verwendet
menu_param.c: In function `openMenu':
menu_param.c:133: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer Breite
ar r libmenu.a menu.o vf_menu.o menu_cmdlist.o menu_pt.o menu_list.o
menu_filesel.o menu_txt.o menu_console.o menu_pa ram.o
ar: creating libmenu.a
true libmenu.a
make[1]: Leaving directory
`/var/tmp/portage/mplayer-1.0_pre6-r4/work/MPlayer-1.0pre6a/libmenu'
cc -I../libvo -I../../libvo -I/usr/X11R6/include  -march=athlon64 -pipe -O2
-frename-registers -D_REENTRANT -D_LARGEF ILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib64/g lib/include -I. -I/usr/include/freetype2 -I/usr/include/gtk-1.2
-I/usr/include/glib-1.2 -I/usr/lib64/glib/include   - I/usr/X11R6/include      
-o mplayer mplayer.o mp_msg.o cpudetect.o codec-cfg.o spudec.o playtree.o
playtreeparser.o asxparser.o vobsub.o subreader.o sub_cc.o find_sub.o m_config.o
m_option.o parser-cfg.o m_struct.o edl.o unrarlib.o m ixer.o parser-mpcmd.o
libvo/libvo.a libao2/libao2.a libmenu/libmenu.a  Gui/libgui.a
libmpcodecs/libmpcodecs.a   libaf /libaf.a libmpdemux/libmpdemux.a
input/libinput.a postproc/libswscale.a osdep/libosdep.a -ldvdread
libavcodec/libavco dec.a libavformat/libavformat.a  -lmad -lvorbis -logg  
-lfaad -llzo -lmp3lame -lvorbis -logg -lxvidcore -lm -ldts -l m -lpng -lz -lz
-ljpeg -lasound -ldl -lpthread /usr/lib/libxmms.so.1 -export-dynamic 
-L/usr/lib64 -Wl,--rpath -Wl,/u sr/lib64 -lfreetype -lz   -lnsl  -lungif   
-L/usr/lib64 -lfontconfig    mp3lib/libMP3.a liba52/liba52.a libmpeg2/lib
mpeg2.a -L/usr/lib64 -L/usr/lib64 -lgtk -lgdk -rdynamic -lgmodule -lglib -lXi
-lXext -lX11 -lm -L/usr/lib64 -lglib  - lGL -lXxf86dga -lXv -lXvMC -lXvMCNVIDIA
-lXxf86vm  -L/usr/X11R6/lib -lXext -lX11 -lnsl -lnsl      -ldirectfb   -L/usr
/lib64 -lesd -laudiofile -lm -lasound         -lpthread -ldl -rdynamic   -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld:
libvo/libvo.a(osd.o): relocation R_X86 _64_32S against `a local symbol' can not
be used when making a shared object; recompile with -fPIC
libvo/libvo.a: could not read symbols: Bad value
collect2: ld gab 1 als Ende-Status zurück
make: *** [mplayer] Fehler 1

!!! ERROR: media-video/mplayer-1.0_pre6-r4 failed.
!!! Function src_compile, Line 509, Exitcode 2
!!! Failed to build MPlayer!
!!! If you need support, post the topmost build error, NOT this status message.


Expected Results:  
successful emerge

Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.4.3,
glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r7 x86_64)
=================================================================
System uname: 2.6.11-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3000+
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.5 [2.3.5 (#1, May 16 2005, 20:15:15)]
dev-lang/python:     2.3.5
sys-apps/sandbox:    [Not Present]
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.8.5-r3, 1.6.3, 1.5, 1.7.9-r1, 1.4_p6, 1.9.5
sys-devel/binutils:  2.15.92.0.2-r8
sys-devel/libtool:   1.5.16
virtual/os-headers:  2.6.8.1-r4
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-march=athlon64 -O3 -pipe -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /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 /usr/X11R6/bin/startx /etc/env.d"
CXXFLAGS="-march=athlon64 -O3 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig candy ccache distlocks sandbox severe sfperms
strict test"
GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/
ftp://ftp.tu-clausthal.de/pub/linux/gentoo/
ftp://ftp.gentoo.mesh-solutions.com/gentoo/
http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/"
LANG="de_DE@euro"
LC_ALL="de_DE@euro"
LINGUAS="de"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="X acpi alsa amd64 avi berkdb bitmap-fonts bzlib cdr crypt cups curl dga
directfb dlloader dts dvd dvdr dvdread eds emacs encode esd exif fam fbcon
font-server fortran gdbm gif gnome gpm gstreamer gtk gtk2 hal hardened howl
imagemagick imlib ipv6 ithreads javascript jp2 jpeg lcms libwww lzo lzw lzw-tiff
mad matroska memlimit mikmod mmap mng mozdevelop mozsvg mp3 mpeg ncurses nls
nvidia ogg oggvorbis opengl oss pam pda pdflib perl png python quicktime
readline real slang ssl svg tcpd tetex tga threads tidy tiff truetype
truetype-fonts type1-fonts unicode usb userlocales videos vorbis wmf xml2 xmms
xpm xprint xrandr xv xvid xvmc zlib linguas_de userland_GNU kernel_linux
elibc_glibc"
Unset:  ASFLAGS, CBUILD, CTARGET, LDFLAGS, PORTDIR_OVERLAY


# emerge -pv --deep --newuse mplayer

These are the packages that I would merge, in order:

Calculating dependencies  ...done!
[ebuild  N    ] media-video/mplayer-1.0_pre6-r4  (-3dfx) (-3dnow) (-3dnowext) +X
-aalib +alsa (-altivec) -arts +avi -bidi -cdparanoia -debug +dga +directfb
(-divx4linux) -doc +dts -dv -dvb +dvd +dvdread -edl +encode +esd +fbcon -ggi
+gif +gtk -i8x0 +ipv6 -jack -joystick +jpeg -libcaca -lirc -live +lzo +mad
+matroska -matrox (-mmx) (-mmxext) +mpeg -mythtv -nas +nls +nvidia +oggvorbis
+opengl +oss +png +real -rtc -samba -sdl (-sse) (-sse2) (-svga) +tga -theora
+truetype -v4l -v4l2 -xanim -xinerama +xmms +xv +xvid +xvmc 0 kB
Comment 2 Diego Elio Pettenò (RETIRED) gentoo-dev 2005-07-13 04:00:35 UTC
Still an issue with latest mplayer? 
 
Comment 3 Attila Stehr 2005-07-13 04:54:54 UTC
yes

cc -c -I../libvo -I../../libvo -I/usr/X11R6/include -O4   -pipe -ffast-math
-fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib64/glib/include -I. -I.. -I../libmpcodecs -I/usr/include/gtk-1.2
-I/usr/include/glib-1.2 -I/usr/lib64/glib/include -Wall -I/usr/include/freetype2
-o menu_param.o menu_param.c
menu_param.c: In function `parse_args':
menu_param.c:83: Warnung: Dereferenzierung eines Type-Pun-Zeigers verletzt
strict-aliasing-Regeln
menu_param.c:93: Warnung: Dereferenzierung eines Type-Pun-Zeigers verletzt
strict-aliasing-Regeln
menu_param.c:56: Warnung: Variable 
Comment 4 Attila Stehr 2005-07-13 04:54:54 UTC
yes

cc -c -I../libvo -I../../libvo -I/usr/X11R6/include -O4   -pipe -ffast-math
-fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib64/glib/include -I. -I.. -I../libmpcodecs -I/usr/include/gtk-1.2
-I/usr/include/glib-1.2 -I/usr/lib64/glib/include -Wall -I/usr/include/freetype2
-o menu_param.o menu_param.c
menu_param.c: In function `parse_args':
menu_param.c:83: Warnung: Dereferenzierung eines Type-Pun-Zeigers verletzt
strict-aliasing-Regeln
menu_param.c:93: Warnung: Dereferenzierung eines Type-Pun-Zeigers verletzt
strict-aliasing-Regeln
menu_param.c:56: Warnung: Variable »ok« wird nicht verwendet
menu_param.c:56: Warnung: Variable »cancel« wird nicht verwendet
menu_param.c: In function `openMenu':
menu_param.c:133: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer Breite
ar r libmenu.a menu.o vf_menu.o menu_cmdlist.o menu_pt.o menu_list.o
menu_filesel.o menu_txt.o menu_console.o menu_param.o
ar: creating libmenu.a
true libmenu.a
make[1]: Leaving directory
`/var/tmp/portage/mplayer-1.0_pre7/work/MPlayer-1.0pre7/libmenu'
cc -I../libvo -I../../libvo -I/usr/X11R6/include -O4   -pipe -ffast-math
-fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib64/glib/include -I. -I/usr/include/freetype2 -I/usr/include/gtk-1.2
-I/usr/include/glib-1.2 -I/usr/lib64/glib/include  -I/usr/include/SDL
-D_REENTRANT -I/usr/X11R6/include       -o mplayer mplayer.o mp_msg.o
cpudetect.o codec-cfg.o spudec.o playtree.o playtreeparser.o asxparser.o
vobsub.o subreader.o sub_cc.o find_sub.o m_config.o m_option.o parser-cfg.o
m_struct.o edl.o unrarlib.o mixer.o parser-mpcmd.o subopt-helper.o libvo/libvo.a
libao2/libao2.a libmenu/libmenu.a  Gui/libgui.a libmpcodecs/libmpcodecs.a  
libaf/libaf.a libmpdemux/libmpdemux.a input/libinput.a postproc/libswscale.a
osdep/libosdep.a -ldvdread libavcodec/libavcodec.a libavformat/libavformat.a 
-lmad    -llzo -lmp3lame  -lxvidcore -lm -ldts -lm -lpng -lz -lz -ljpeg -lasound
-ldl -lpthread /usr/lib64/libxmms.so.1 -export-dynamic  -L/usr/lib64 -Wl,--rpath
-Wl,/usr/lib64 -lfreetype -lz   -lnsl  -lungif    -L/usr/lib64 -lfontconfig   
libfaad2/libfaad2.a  mp3lib/libMP3.a liba52/liba52.a libmpeg2/libmpeg2.a
tremor/libvorbisidec.a -L/usr/lib64 -L/usr/lib64 -lgtk -lgdk -rdynamic -lgmodule
-lglib -lXi -lXext -lX11 -lm -L/usr/lib64 -lglib  -lGL -lXxf86dga -lXv -lXvMC
-lXvMCNVIDIA -lXxf86vm  -L/usr/X11R6/lib -lXext -lX11 -lnsl -lnsl -L/usr/lib64
-Wl,-rpath,/usr/lib -lSDL -lpthread     -ldirectfb   -L/usr/lib64 -lesd
-laudiofile -lm -lasound         -lpthread -ldl -rdynamic   -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld:
libvo/libvo.a(osd.o): relocation R_X86_64_32S against `a local symbol' can not
be used when making a shared object; recompile with -fPIC
libvo/libvo.a: could not read symbols: Bad value
collect2: ld gab 1 als Ende-Status zurück
make: *** [mplayer] Fehler 1

!!! ERROR: media-video/mplayer-1.0_pre7 failed.
!!! Function src_compile, Line 488, Exitcode 2
!!! Failed to build MPlayer!

No error found in log file.

--- lots of warnings ---
menu_param.c:83: Warnung: Dereferenzierung eines Type-Pun-Zeigers verletzt
strict-aliasing-Regeln

mplayer/gtk/eq.c: In function `eqSetBands':
mplayer/gtk/eq.c:71: Warnung: implizite Deklaration der Funktion »get_video_colors«
mplayer/gtk/eq.c: In function `eqHScaleMotion':
mplayer/gtk/eq.c:162: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer
Breite
mplayer/gtk/eq.c:177: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer
Breite
mplayer/gtk/eq.c: In function `eqVScaleMotion':
mplayer/gtk/eq.c:191: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer
Breite
mplayer/gtk/eq.c: In function `eqButtonReleased':
mplayer/gtk/eq.c:204: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer
Breite
mplayer/gtk/eq.c: In function `ecButtonReleased':
mplayer/gtk/eq.c:541: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer
Breite
mplayer/gtk/eq.c:543: Warnung: Dereferenzierung eines Type-Pun-Zeigers verletzt
strict-aliasing-Regeln

mplayer/gtk/opts.c: In function `create_Preferences':
mplayer/gtk/opts.c:1173: Warnung: implizite Deklaration der Funktion
»get_video_quality_max«
mplayer/gtk/opts.c:760: Warnung: Variable »hbuttonbox2« wird nicht verwendet
mplayer/gtk/opts.c:768: Warnung: Variable »hbox3« wird nicht verwendet
mplayer/gtk/opts.c: In function `audioButton':
mplayer/gtk/opts.c:1472: Warnung: Typkonvertierung von Zeiger auf Ganzzahl
anderer Breite
mplayer/gtk/opts.c:1476: Warnung: Verarbeiten des Argumentes 1 von »gfree« von
inkompatiblem Zeigertyp

mplayer/gtk/menu.c: In function `AddMenuCheckItem':
mplayer/gtk/menu.c:100: Warnung: Typkonvertierung in Zeiger von Ganzzahl anderer
Breite

skin/skin.c: In function `cmd_base':
skin/skin.c:137: Warnung: zu wenig Argumente für Format
Comment 5 Attila Stehr 2005-07-13 05:01:42 UTC
probably helpful translation:

menu_param.c:83: Warnung: Dereferenzierung eines Type-Pun-Zeigers verletzt
strict-aliasing-Regeln
=> dereferencing a type-pun-pointer "hurts" strict-alias rules

mplayer/gtk/eq.c:162: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer
Breite
=> type conversion from pointer to integer of other ... length / size (?!)

mplayer/gtk/opts.c:760: Warnung: Variable 
Comment 6 Attila Stehr 2005-07-13 05:01:42 UTC
probably helpful translation:

menu_param.c:83: Warnung: Dereferenzierung eines Type-Pun-Zeigers verletzt
strict-aliasing-Regeln
=> dereferencing a type-pun-pointer "hurts" strict-alias rules

mplayer/gtk/eq.c:162: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer
Breite
=> type conversion from pointer to integer of other ... length / size (?!)

mplayer/gtk/opts.c:760: Warnung: Variable »hbuttonbox2« wird nicht verwendet
=> var ... not used

mplayer/gtk/opts.c:1476: Warnung: Verarbeiten des Argumentes 1 von »gfree« von
inkompatiblem Zeigertyp
=> "elaboration" of argument 1 of gfree of incompatilbe pointer type

skin/skin.c:137: Warnung: zu wenig Argumente für Format
=> under (too few) arguments for Fromat
Comment 7 Christian H. Kuhn 2005-08-06 10:15:15 UTC
I can confirm that error. Additionaly, after removing "unset CFLAGS CXXFLAGS" in
the ebuild, the command contains -fPIC, and the error persists.
Comment 8 Chad Granum 2005-08-26 16:32:58 UTC
I am encountering the same issue:

make[1]: Leaving directory
`/var/tmp/portage/mplayer-1.0_pre7/work/MPlayer-1.0pre7/libmenu'
cc -I../libvo -I../../libvo -I/usr/X11R6/include -O4   -pipe -ffast-math
-fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib64/glib/include -I.
-I/usr/include/freetype2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib64/glib/include  -I/usr/include/SDL -D_REENTRANT -I/usr/X11R6/include
      -o mplayer mplayer.o mp_msg.o cpudetect.o codec-cfg.o spudec.o playtree.o
playtreeparser.o asxparser.o vobsub.o subreader.o sub_cc.o find_sub.o m_config.o
m_option.o parser-cfg.o m_struct.o edl.o unrarlib.o mixer.o parser-mpcmd.o
subopt-helper.o libvo/libvo.a libao2/libao2.a libmenu/libmenu.a  Gui/libgui.a
libmpcodecs/libmpcodecs.a   libaf/libaf.a libmpdemux/libmpdemux.a
input/libinput.a postproc/libswscale.a osdep/libosdep.a -Llibmpdvdkit2
-lmpdvdkit libavcodec/libavcodec.a libavformat/libavformat.a  -lmad    -llzo
-lmp3lame  -lxvidcore -lm  -lpng -lz -lz -ljpeg -lasound -ldl -lpthread
/usr/lib64/libxmms.so.1 -export-dynamic  -L/usr/lib64 -Wl,--rpath -Wl,/usr/lib64
-lfreetype -lz  -lcdda_interface -lcdda_paranoia
/usr/lib64/live/liveMedia/libliveMedia.a
/usr/lib64/live/groupsock/libgroupsock.a
/usr/lib64/live/UsageEnvironment/libUsageEnvironment.a
/usr/lib64/live/BasicUsageEnvironment/libBasicUsageEnvironment.a -lstdc++  -lnsl
 -lgif  -lsmbclient  -L/usr/lib64 -lfontconfig    libfaad2/libfaad2.a 
mp3lib/libMP3.a liba52/liba52.a libmpeg2/libmpeg2.a tremor/libvorbisidec.a
-L/usr/lib64 -L/usr/lib64 -lgtk -lgdk -rdynamic -lgmodule -lglib -lXi -lXext
-lX11 -lm -L/usr/lib64 -lglib -laa -lGL  -lXv -lXvMC -lXvMCNVIDIA -lXxf86vm
-lXinerama -L/usr/X11R6/lib -lXext -lX11 -lnsl -lnsl -L/usr/lib64
-Wl,-rpath,/usr/lib -lSDL -lpthread     -ldirectfb   -L/usr/lib64 -lesd
-laudiofile -lm -lasound         -lpthread -ldl -rdynamic   -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld:
libvo/libvo.a(osd.o): relocation R_X86_64_32S against `a local symbol' can not
be used when making a shared object; recompile with -fPIC
libvo/libvo.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [mplayer] Error 1

!!! ERROR: media-video/mplayer-1.0_pre7 failed.
!!! Function src_compile, Line 487, Exitcode 2
!!! Failed to build MPlayer!
!!! If you need support, post the topmost build error, NOT this status message. 


emerge info:

Portage 2.0.51.22-r2 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r1,
2.6.12-gentoo-r9-Abydos x86_64)
=================================================================
System uname: 2.6.12-gentoo-r9-Abydos x86_64 AMD Athlon(tm) 64 Processor 3500+
Gentoo Base System version 1.6.13
ccache version 2.3 [enabled]
dev-lang/python:     2.3.5
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=k8 -fomit-frame-pointer -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=k8 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://192.168.0.4/gentoo-portage"
USE="amd64 X aa;ib aac aalib alsa avi bash-completion berkdb bitmap-fonts bzip2
cdparanoia cdr crypt cups curl directfb dvd dvdr eds encode esd fam ffmpeg flac
flash foomaticdb fortran ftp gif gimp-print gpm gstreamer gtk gtk2 hardened
imlib ipv6 java jpeg junit lzo lzw lzw-tiff mad mozilla mp3 mpeg ncurses nls ogg
openal opengl pam pcre pdflib perl png python quicktime readline samba sdl spell
ssl tcpd tiff truetype truetype-fonts type1-fonts usb userlocales vorbis
xinerama xml2 xmms xpm xv zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY

snippet of /etc/portage/packages.use
----------
media-video/mplayer doc live matroska mmx nvidia rtc sse sse2 v4l v4l2 xanim
xinerama xvid xvmc
----------
Comment 9 Chad Granum 2005-08-26 19:38:00 UTC
I just realised both of us are using hardened, I encountered several other
issues due to hardnedned and it is only in my use flags by accident (copied
wrong systems make.conf on install) re-injstalling w/o hardned (fresh bootstrap
and format) will notify on next attempt to install mplayer w/o hardened.
Comment 10 Chad Granum 2005-08-26 19:41:27 UTC
(In reply to comment #6)
> I just realised both of us are using hardened, I encountered several other
> issues due to hardnedned and it is only in my use flags by accident (copied
> wrong systems make.conf on install) re-injstalling w/o hardned (fresh bootstrap
> and format) will notify on next attempt to install mplayer w/o hardened.

http://bugs.gentoo.org/show_bug.cgi?id=96103

another amd64 user with hardened use flags having same mplayer problem.
Comment 11 Attila Stehr 2005-08-26 19:56:09 UTC
Um ... thats a bug report I did.
I 'removed' the mplayer problem from bug #96103 'in favour' of this one.
Comment 12 Chad Granum 2005-08-27 11:35:35 UTC
ok, on a fresh install (format, bootstrap, system) without the hardened use flag
mplayer installed fine.  hardened was tyhe only difference. My guess it is a
problem with that.

If I had niot removed my hardened install I would have tried the same workaround
that was used for xorg on hardened:

USE="-hardened" emerge gcc   #emerges a second gcc without hardeneded
gcc-config  #use this to select the vanila or any non-hardened gcc install
USE="-hardened" emerge mplayer

that is what I would try, but can't no more hardened on my system.
Comment 13 Attila Stehr 2005-08-27 19:07:17 UTC
I had / have no problems with xorg...

[ebuild   R   ] x11-base/xorg-x11-6.8.2-r2  (-3dfx) (-3dnow) +bitmap-fonts -cjk
-debug +dlloader -dmx -doc -font-server* -insecure-drivers +ipv6 -minimal (-mmx)
+nls -nocxx +opengl +pam -sdk (-sse) -static +truetype-fonts +type1-fonts
(-uclibc) +xprint +xv 9 kB

But, I can't emerge audacity & crystalspace (planeshift) and have problems with
xine-ui.
Is it well known that having the hardened use flag breaks some packages?
Comment 14 Jakub Moc (RETIRED) gentoo-dev 2005-08-28 01:02:59 UTC
*** Bug 104004 has been marked as a duplicate of this bug. ***
Comment 15 Kevin F. Quinn (RETIRED) gentoo-dev 2005-08-28 04:41:19 UTC
Attila - "hardened" causes various compiler and linker options to be switched on
by default, amongst other things.  Usually these options don't cause any
problem.  However some packages, particularly those with hand-written 32-bit x86
assembler code can fail.  This is common in the media packages where the only
way to get any kind of decent throughput from the 32-bit x86 architecture with
gcc is to write low-level assembler code by hand, and this is often not
compatible with the hardened compiler options.

If you come across packages that fail to emerge, please raise a separate bug for
each package (unless there's already one open).  Usually we can find a way to
get it to work without sacrificing the hardened features; this often means
sacrificing some performance of course, but that's only really a problem for
older (slower) systems.
Comment 16 Attila Stehr 2005-08-28 09:18:13 UTC
> If you come across packages that fail to emerge, please raise a separate 
> bug for each package (unless there's already one open).  Usually we can 
> find a way to get it to work without sacrificing the hardened features;

please see
bug #100067 (audacity)
bug #102829 (crystalspace)
bug # 96073 (xine-ui)
as well as
bug # 99764 and 96103 (both refering to alsa problems)
Comment 17 disperato 2005-08-28 09:55:20 UTC
thanks to you all I solved by:
adding -fPIC to CFLAGS
adding -hardened to USE flags
*both* necessary (I first tried with the only -hardened and it fails) and both,
temporarely added to /etc/make.conf (no command line)

emerge gcc (updated to 3.4.4-r1)
emerge mplayer

mplayer compiled and works fine!
the same for synaptics, my bug #102156: ok now!
thanks again
Comment 18 Kevin F. Quinn (RETIRED) gentoo-dev 2005-08-28 12:53:45 UTC
attila: regarding the audacity, crystalspace and xine-ui bugs they don't look
like hardened problems so far.  To prove otherwise, try building them with the
vanilla compiler (use gcc-config to switch) and see if the problems go away.
Comment 19 Attila Stehr 2005-08-29 19:28:04 UTC
Kevin:

Crystalspace emerges with gcc-vanilla - see bug # 102829. 
Same with xine-ui - see bug # 96073.

The bug number for audacity was wrong. The bug I had in mind refers to segfaults
when starting audacity - it's bug # 100741.
And, -  what a coincidence >:-[ ... this was the point where I got really angry
(on the handbook) - audacity works as well now. 

Anyway, tyvm for your hint!



Maybe I just didn't find it yet, but I wonder if there is a document on the
gentoo homepage called "troubleshooting". Some ideas:
- "the hardened issue"
- "update the system" as stated in
http://www.gentoo.org/doc/en/new-upgrade-to-gentoo-1.4.xml

Then, the troubleshooting document as well as the gentoo-bug-reporting-guide
http://www.gentoo.org/doc/en/bugzilla-howto.xml should be linked in the handbook
(not 10 clicks away under 'documentation resources' since nobody does that).
This would save reporters and _devs_ time and HD capacity and our all nerves >:-[.

btw: The bug-reporting-guide seems not to be sufficient. See
https://bugs.gentoo.org/show_bug.cgi?id=96073#c25
Shall I open a new bug report that for?

There was some other thoughts on that which I can't remember now.


Probably most of the most of the other bugs I reported can be "managed" by not
using hardened as well...
Comment 20 Attila Stehr 2006-05-12 03:10:47 UTC
summary altered
Comment 21 JG 2006-06-20 10:30:22 UTC
I am also having this issue with hardened on amd64:

ar: creating libmenu.a
true libmenu.a
make[1]: Leaving directory `/var/tmp/portage/mplayer-1.0.20060415/work/mplayer-1.0.20060415/libmenu'
cc -I../libvo -I../../libvo -I/usr/X11R6/include -O4 -D__STDC_LIMIT_MACROS   -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE  -I.   -I/usr/include   -I/usr/include/freetype2   -I/usr/X11R6/include   -I./libavutil -I./libavcodec   -o mplayer mplayer.o m_property.o mp_msg.o asxparser.o codec-cfg.o cpudetect.o edl.o find_sub.o m_config.o m_option.o m_struct.o parser-cfg.o playtree.o playtreeparser.o spudec.o sub_cc.o subreader.o vobsub.o unrarlib.o mixer.o parser-mpcmd.o subopt-helper.o libvo/libvo.a libao2/libao2.a libmenu/libmenu.a  Gui/libgui.a libmpcodecs/libmpcodecs.a   libaf/libaf.a libmpdemux/libmpdemux.a input/libinput.a postproc/libswscale.a osdep/libosdep.a -ldvdread libavcodec/libavcodec.a  libavformat/libavformat.a  libavutil/libavutil.a  libavcodec/libpostproc/libpostproc.a  -lmad -ldv -ltheora -logg  -llzo -lmp3lame  -lxvidcore -ldts -lpng -lz -lz -ljpeg -lasound -ldl -lpthread /usr/lib64/libxmms.so.1 -export-dynamic -lx264 -lpthread -lmpcdec -lspeex  -lfaac -lfreetype -lz -lncurses -lcdda_interface -lcdda_paranoia /usr/lib64/live/liveMedia/libliveMedia.a /usr/lib64/live/groupsock/libgroupsock.a /usr/lib64/live/UsageEnvironment/libUsageEnvironment.a /usr/lib64/live/BasicUsageEnvironment/libBasicUsageEnvironment.a -lstdc++  -lnsl   -lgif    -lfontconfig   libfaad2/libfaad2.a  mp3lib/libMP3.a liba52/liba52.a libmpeg2/libmpeg2.a tremor/libvorbisidec.a -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   -lglib-2.0    -lGL -ldl -lXxf86dga -lXv  -lXxf86vm -lXinerama -L/usr/X11R6/lib -lXext -lX11 -lnsl -lpthread -lnsl  -lggi                -Wl,-z,noexecstack  -llirc_client   -lpthread -ldl -rdynamic  -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../x86_64-pc-linux-gnu/bin/ld: libvo/libvo.a(osd.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
libvo/libvo.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [mplayer] Error 1
Comment 22 Christian Korff 2006-08-04 03:32:09 UTC
This bug is over a year old?

It's maybe intresting for the bugreport but the actual code (just some days ago) which is in the subversion repository fails to build too.
Comment 23 Olliver Schinagl 2006-09-19 04:05:01 UTC
I also still can't get mplayer 1.0 pre8 to RUN with a hardened profile/toolchain/kernel.

It compiles fine, with -fno-PIC passing by many times however. Obviously it fails to run with a nice permission denied error.
Comment 24 Luca Barbato gentoo-dev 2006-12-10 18:25:36 UTC
As expected since mplayer does lots of scary things on x86 to squeeze the last drop of performance out of it...

I guess the only thing I could do is add an ewarn and some direction to let mplayer do its stuff... Hardened people do you have any documentation about it already?
Comment 25 Olliver Schinagl 2006-12-11 05:36:35 UTC
paxctl iirc 'helps' but makes your mplayer insecure, I believe it was one of the supporting libraries that I had a problem with.
Comment 26 Kevin F. Quinn (RETIRED) gentoo-dev 2006-12-11 09:17:55 UTC
It's perhaps more accurate to say that mplayer does a bunch of dodgy stuff in the often mistaken belief they are getting maximum performance - however that aside, it's enough to add:

filter-flags -fPIE

to get working executables (well, it plays mpg files for me, anyway).  This will do the necessary thing to prevent the hardened compiler generating PIE code; the cost being that exploits against any insecurities in the mplayer code will be repeatable (and hence predictable, and so easily exploitable).  I added it after the 'if use custom-cflags' section, just before the configure call:

...
    fi
    filter-flags -fPIE

    CFLAGS="$CFLAGS" ./configure \
...

and that worked for me on x86.  Should be ok on amd64 as well, although it might be worth experimenting more there - depends how smart the mplayer people have been in using x86_64 assembler.
Comment 27 Kevin F. Quinn (RETIRED) gentoo-dev 2006-12-11 09:18:56 UTC
(In reply to comment #20)
> It compiles fine, with -fno-PIC passing by many times however. Obviously it
> fails to run with a nice permission denied error.

You need to be more specific.  Exactly what error did you see.
Comment 28 Olliver Schinagl 2006-12-11 15:46:26 UTC
It was something like this:
LoadPlugin: failed to initialize shared library /opt/netscape/plugins/libflashplayer.so [/opt/netscape/plugins/libflashplayer.so: cannot make segment writable for relocation: Permission denied]

but then for mplayer with a different library (I don't remember which one). using paxctl 'fixed' it for mplayer to become usable. I know it's bad, but what can a poor user do?
Comment 29 Kevin F. Quinn (RETIRED) gentoo-dev 2006-12-11 16:37:11 UTC
(In reply to comment #25)
> [/opt/netscape/plugins/libflashplayer.so: cannot make segment writable for
> relocation: Permission denied]
> 
> but then for mplayer with a different library (I don't remember which one).

When it happens again, could you raise it as a separate bug, describing exactly the command you used, and the file you were trying to play?  It's a different issue to the one this bug is about.  Thanks.
Comment 30 Attila Stehr 2006-12-12 12:38:02 UTC
(In reply to comment #23)
> I added it after the 'if use custom-cflags' section, just before the configure call:
> 
> ...
>     fi
>     filter-flags -fPIE
> 
>     CFLAGS="$CFLAGS" ./configure \
> ...
> 
> and that worked for me on x86.  Should be ok on amd64 as well, although it

approving, works on (my) AMD64 (machine)

> might be worth experimenting more there - depends how smart the mplayer people
> have been in using x86_64 assembler.

Well then, instructions please! :)
Comment 31 Dan Reidy 2009-01-11 23:30:43 UTC
*bump*
still an issue
Comment 32 Steve Dibb (RETIRED) gentoo-dev 2009-01-13 20:11:16 UTC
*** Bug 254494 has been marked as a duplicate of this bug. ***
Comment 33 Hugo Mildenberger 2009-04-13 05:34:17 UTC
Created attachment 188181 [details, diff]
patch 1/2: remove all mmx related cpu features on hardened
Comment 34 Hugo Mildenberger 2009-04-13 05:40:09 UTC
Created attachment 188183 [details, diff]
patch 2/2: make inclusion of mmx/sse related assembly routines dependand on config

These two patches should solve this issue at least on hardened amd64.
Comment 35 Samuli Suominen (RETIRED) gentoo-dev 2009-08-03 18:54:21 UTC
*** Bug 246434 has been marked as a duplicate of this bug. ***
Comment 36 Samuli Suominen (RETIRED) gentoo-dev 2009-08-03 21:06:31 UTC
*** Bug 269103 has been marked as a duplicate of this bug. ***
Comment 37 Samuli Suominen (RETIRED) gentoo-dev 2009-08-03 21:07:43 UTC
*** Bug 175627 has been marked as a duplicate of this bug. ***
Comment 38 Samuli Suominen (RETIRED) gentoo-dev 2009-08-03 22:30:17 UTC
*** Bug 133586 has been marked as a duplicate of this bug. ***
Comment 39 Samuli Suominen (RETIRED) gentoo-dev 2009-08-03 22:32:32 UTC
*** Bug 122524 has been marked as a duplicate of this bug. ***
Comment 40 Samuli Suominen (RETIRED) gentoo-dev 2009-08-04 13:20:52 UTC
*** Bug 256909 has been marked as a duplicate of this bug. ***
Comment 41 detrito 2009-08-04 17:06:14 UTC
I confirm this bug for x86 hardened-profiles. today I tried to emerge mplayer with various combinations of CFLAGS and compilers on a fresh installed machine. the results:

* without mmx, sse and sse2 (-3dnow -sse -sse2 -mmx custom-cpuopts in /etc/portage/package.use)

[ebuild   R   ] media-video/mplayer-1.0_rc2_p20090731  USE="a52 aac alsa ass cddb cdio custom-cpuopts* dirac dts dv dvd dvdnav enca encode faac faad gif iconv jpeg live mad mp2 mp3 network opengl osdmenu png quicktime rar real rtc schroedinger shm speex theora tremor truetype vorbis x264 xscreensaver xv xvid -3dnow -3dnowext -X -aalib (-altivec) -bidi -bindist -bl -cdparanoia -cpudetection -custom-cflags -debug -dga -directfb -doc -dvb -dxr3 -esd -fbcon -ftp -ggi -gmplayer -ipv6 -jack -joystick -ladspa -libcaca -lirc -lzo -md5sum -mmx* -mmxext -mng -nas -nut -openal -oss -pnm -pulseaudio -pvr -radio -samba -sdl -sse* -sse2* -ssse3 -svga -teletext -tga -unicode -v4l -v4l2 (-vdpau) -vidix -win32codecs -xanim -xinerama -xvmc -zoran" VIDEO_CARDS="mga s3virge tdfx vesa (-nvidia)" 0 kB

compiles with:
- i686-pc-linux-gnu-3.4.6-hardenednopie

does not compiles with:
- i686-pc-linux-gnu-3.4.6


* with mmx, sse and sse2 (my standard cpu flags)

Calculating dependencies... done!
[ebuild   R   ] media-video/mplayer-1.0_rc2_p20090731  USE="a52 aac alsa ass cddb cdio dirac dts dv dvd dvdnav enca encode faac faad gif iconv jpeg live mad mmx* mp2 mp3 network opengl osdmenu png quicktime rar real rtc schroedinger shm speex sse* sse2* theora tremor truetype vorbis x264 xscreensaver xv xvid -3dnow -3dnowext -X -aalib (-altivec) -bidi -bindist -bl -cdparanoia -cpudetection -custom-cflags -custom-cpuopts -debug -dga -directfb -doc -dvb -dxr3 -esd -fbcon -ftp -ggi -gmplayer -ipv6 -jack -joystick -ladspa -libcaca -lirc -lzo -md5sum -mmxext -mng -nas -nut -openal -oss -pnm -pulseaudio -pvr -radio -samba -sdl -ssse3 -svga -teletext -tga -unicode -v4l -v4l2 (-vdpau) -vidix -win32codecs -xanim -xinerama -xvmc -zoran" VIDEO_CARDS="mga s3virge tdfx vesa (-nvidia)" 0 kB

compiles with:
- i686-pc-linux-gnu-3.4.6-hardenednopie

does not compiles with:
- i686-pc-linux-gnu-3.4.6

with both the compiled binaries I was able to play mp3, ogg and flac audio files.
Comment 42 Enchant 2009-08-05 07:49:12 UTC
I confirm it. If execute:

 $ gcc-config i686-pc-linux-gnu-3.4.6-hardenednopie
 $ env-update ; source /etc/profile
 $ emerge media-video/mplayer -1av
___
Calculating dependencies... done!
[ebuild   R   ] media-video/mplayer-1.0_rc2_p20090322  USE="a52 aac ass cpudetection encode faac faad gif iconv jpeg mad md5sum mmx mp2 mp3 network png quicktime theora tremor truetype unicode vidix vorbis win32codecs x264 xvid -3dnow -3dnowext -X -aalib -alsa (-altivec) -amrnb -amrwb -arts -bidi -bindist -bl -cddb -cdio -cdparanoia -custom-cflags -custom-cpuopts -debug -dga -dirac -directfb -doc -dts -dv -dvb -dvd -dvdnav -dxr3 -enca -esd -fbcon -ftp -ggi -gtk -ipv6 -jack -joystick -ladspa -libcaca -lirc -live -lzo -mmxext -mng -musepack -nas -nemesi -openal -opengl -oss -pnm -pulseaudio -pvr -radio -rar -real -rtc -samba -schroedinger -sdl -speex -sse -sse2 -ssse3 -svga -teletext -tga -v4l -v4l2 (-vdpau) -xanim -xinerama -xscreensaver -xv -xvmc -zoran" VIDEO_CARDS="-mga (-nvidia) -s3virge -tdfx -vesa"
___

compiled - ok, but does not compiles with i686-pc-linux-gnu-3.4.6
Comment 43 Robert Buchholz (RETIRED) gentoo-dev 2009-08-17 11:28:21 UTC
(In reply to comment #34)
> Created an attachment (id=188183) [edit]
> make inclusion of mmx/sse related assembly routines dependand on config
> 
> These two patches should solve this issue at least on hardened amd64.

The "if HAVE_3DNOW" lines will just remove the code as HAVE_3DNOW is not defined anywhere. Did you mean AMD3DNOW (and AMD3DNOWEXT)?
On the other hand, this marco is redefined earlier in imdct.c, so it seems not to do what we want.

Luca, do you have any input on how to avoid assembly on x86/amd64 in mplayer cleanly?
Comment 44 Reimar Döffinger 2009-08-19 06:49:58 UTC
All asm in MPlayer can be disabled with --target=generic.
Not that the result is a usable player.
A few #ifndef PIC about the problematic code might be the right solution (though these issues are 64 bit-specific, so it is not quite the right condition).
Comment 45 Samuli Suominen (RETIRED) gentoo-dev 2009-08-24 19:36:06 UTC
*** Bug 184003 has been marked as a duplicate of this bug. ***
Comment 46 Honza 2009-09-07 17:04:08 UTC
Is removing of MMX/SSE/3DNow really necessary? Isn't possible to rewrite the asm code to work with hardened compiler? Especially AMD64 should have enough registers ...
Comment 47 Kristian Kallenberg 2009-09-07 19:05:10 UTC
To build mplayer i switched to:

i686-pc-linux-gnu-3.4.6-hardenednopiessp

and ran:

# USE="-hardened" emerge mplayer

that solved the issues for me. I am using x86 on an selinux enabled system.
Comment 48 Samuli Suominen (RETIRED) gentoo-dev 2009-09-09 00:52:27 UTC
*** Bug 78613 has been marked as a duplicate of this bug. ***
Comment 49 Reimar Döffinger 2009-09-14 14:52:41 UTC
Latest MPlayer SVN compiles for me with "--disable-liba52-internal --disable-liba52 --yasm=no" as PIE executable. I don't know if hardened has requirements beyond that though.
Comment 50 Samuli Suominen (RETIRED) gentoo-dev 2009-10-31 18:04:59 UTC
*** Bug 291314 has been marked as a duplicate of this bug. ***
Comment 51 Reimar Döffinger 2009-11-07 18:22:11 UTC
Could someone either test or give me a link on how to set up a hardened gentoo (actually a 32 and 64 bit qemu image would be perfect, but I guess that is asking for too much)?
Note that 32 bit MPlayer will probably always contain textrels and thus not be that suitable for hardened, but 64 bit seems to work just fine for me, even without disabling liba52 and yasm.
Comment 52 Reimar Döffinger 2009-11-07 23:14:32 UTC
Ok, I finally noticed that there is a hardened stage3 available.
Results on amd64, with ~amd64 MPlayer:
Something adds -nopie to the compiler flags, but not to the linker flags.
That is complete nonsense (-nopie is usually only necessary for the linking stage when compilation issues are a problem, not performance, so it should be in LDFLAGS).
In addition on amd64 it would compile fine if yasm was disabled and -nopie not used at all - with the use flags I tried with at least.
Comment 53 disperato 2009-11-07 23:41:22 UTC
email removed
Comment 54 Reimar Döffinger 2009-11-07 23:52:00 UTC
The yasm issue can be fixed with this patch:
http://news.gmane.org/find-root.php?message_id=%3c20091107234736.GA23949%401und1.de%3e
The only thing that is then necessary to have PIE-enabled MPlayer on AMD64 is to disable the
filter-flags -fPIC -fPIE
for AMD64 and fix it to add -nopie to LDFLAGS for 32 bit.
Comment 55 Attila Stehr 2009-11-08 15:16:42 UTC
*cough* ... isn't PIE/PIC what we want when using a hardened profile?! Imo the code should be "compilable" w/o disabling ASM (speed-up) code and w/o disabling PIC/PIE!
Comment 56 Reimar Döffinger 2009-11-08 15:31:20 UTC
Then use a 64 bit or non-x86 system (and currently MPlayer SVN without ebuild+my proposed patch).
Nobody is going to rewrite all the asm and either have worse performance for all other cases or duplicate all the code just to make it work as PIC (i.e. without textrels), and even if someone did I doubt it could ever fit the standards for inclusion in FFmpeg.
And that is not even going into the really difficult stuff like win32, quicktime and real codecs.
However personally I'd be in favour of getting rid of as much filter-flags stuff as possible and instead e.g. print a big fat warning. I always disliked this kind of behaviour that IMHO assumes users are stubborn, don't know what they are doing and incapable of learning.
Comment 57 Samuli Suominen (RETIRED) gentoo-dev 2009-12-21 15:05:30 UTC
*** Bug 297787 has been marked as a duplicate of this bug. ***
Comment 58 Xake 2010-03-02 08:19:31 UTC
(In reply to comment #54)
> for AMD64 and fix it to add -nopie to LDFLAGS for 32 bit.
> 

-pie
    Produce a position independent executable on targets which support it. For predictable results, you must also specify the same set of options that were used to generate code (-fpie, -fPIE, or model suboptions) when you specify this option. [1]

So with other words, you should rather add CFLAGS to your link-command in mplayer Makefile.
Comment 59 Xake 2010-03-02 08:26:11 UTC
Created attachment 221757 [details, diff]
A ("workaround"?) pach

This patch against mplayer ebuild adds CFLAGS to the linker command (as adviced by gcc, also makes filter-flags work), and makes filter-flags depend on x86, since as pointed out mplayer seems to at least compile fine and play on hardened amd64 (also tested here).

@hardened
@media
Could we accept defeat for x86, apply this and move on?
Comment 60 Jory A. Pratt gentoo-dev 2010-03-02 13:40:55 UTC
(In reply to comment #59)
> Created an attachment (id=221757) [details]
> A ("workaround"?) pach
> 
> This patch against mplayer ebuild adds CFLAGS to the linker command (as adviced
> by gcc, also makes filter-flags work), and makes filter-flags depend on x86,
> since as pointed out mplayer seems to at least compile fine and play on
> hardened amd64 (also tested here).
> 
> @hardened
> @media
> Could we accept defeat for x86, apply this and move on?
> 
+1
Comment 61 Reimar Döffinger 2010-03-02 18:27:49 UTC
If you want CFLAGS in LDFLAGS then just add CFLAGS to LDFLAGS, there's no need to hack the Makefile for that.
However a much more reliable solution would be to add "append-ldflags -nopie" eclass/flag-o-matic.eclass:_filter-hardened
Comment 62 Xake 2010-03-02 18:42:42 UTC
(In reply to comment #61)
> If you want CFLAGS in LDFLAGS then just add CFLAGS to LDFLAGS, there's no need
> to hack the Makefile for that.
> However a much more reliable solution would be to add "append-ldflags -nopie"
> eclass/flag-o-matic.eclass:_filter-hardened
> 

Still, if the manual for GCC says you should add the CFLAGS while linking for a predictable result, I would go for adding CFLAGS to LDFLAGS in Gentoo for all (if that is what mplayer upstream thinks that is better then doing a "$(CC) $(CFLAGS) $(LDFLAGS)" when linking which seems to be what most other projects (like kvm or autotools-based) do) just for the sake of what GCC recommends.
Comment 63 Reimar Döffinger 2010-03-03 18:54:26 UTC
First, this way of handling CFLAGS and LDFLAGS is what FFmpeg does, thus doing it differently would not be a good idea for MPlayer. And FFmpeg supports a lot more compilers than just gcc.
Also I'd be interested where in the gcc manual it says you should use CFLAGS for linking, "info gcc" at least does not mention CFLAGS at all. It seems rather silly, since that would mean you would be linking also C++ programs with CFLAGS, and there are many gcc options that make only sense for C.
Comment 64 Xake 2010-03-03 21:12:00 UTC
(In reply to comment #63)
>First, this way of handling CFLAGS and LDFLAGS is what FFmpeg does, thus doing
>it differently would not be a good idea for MPlayer. And FFmpeg supports a lot
>more compilers than just gcc.

Could you please point out what compiler does not handle having CFLAGS passed during linking? 
AFAICS bot ICC and gcc (and derivs) seems to manage, but I have not had the time check up what compilers FFMpeg supports, or which C99 compliant compilers does not support this kind of linking.

> Also I'd be interested where in the gcc manual it says you should use CFLAGS
> for linking, "info gcc" at least does not mention CFLAGS at all.

I see now I forgot to post the link.
http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Link-Options.html
Has been the same for all versions of gcc I have looked up, scroll down to "-pie" and "-shared". It does not specify CFLAGS, but I cannot parse "you must also specify the same set of options that were used to generate code" in any other way.
Comment 65 Jory A. Pratt gentoo-dev 2010-03-18 00:45:50 UTC
amd64 and all other archs other then x86 have been addressed here already in tree. I say lets get this closed already.
Comment 66 Alexis Ballier gentoo-dev 2010-06-25 11:45:54 UTC
*** Bug 324693 has been marked as a duplicate of this bug. ***
Comment 67 Bart Lauwers 2010-06-29 14:39:43 UTC
AMD64: mainstream ebuild fails to compile, media-video/mplayer-1.0_rc4_p20100612 works out of the box
Comment 68 Jaak Ristioja 2010-07-15 21:31:07 UTC
(In reply to comment #67)
> AMD64: mainstream ebuild fails to compile,
> media-video/mplayer-1.0_rc4_p20100612 works out of the box

I can confirm that the current stable version (1.0_rc4_p20091026-r1) fails to compile, but media-video/mplayer-1.0_rc4_p20100612 emerges just fine.
Comment 69 Reimar Döffinger 2010-07-18 09:15:55 UTC
If someone provided at least some kind of details about the AMD64 issue it might actually get fixed...
Comment 70 7v5w7go9ub0o 2010-07-18 15:43:52 UTC
FWIW I've been having no trouble compiling/using mplayer for quite a while (actually Nikos Chantziaras's overlay   <http://bugs.gentoo.org/show_bug.cgi?id=282154> ). I thought the hardened issues went away with gcc 4.3/4.4.

(ISTM there are "broken with hardened" concerns out there that simply no longer apply (e.g. lilo); perhaps this is one?)

# gcc-config -l
 [1] x86_64-pc-linux-gnu-4.3.5
 [2] x86_64-pc-linux-gnu-4.3.5-hardenednopie
 [3] x86_64-pc-linux-gnu-4.3.5-vanilla
 [4] x86_64-pc-linux-gnu-4.4.4 *
 [5] x86_64-pc-linux-gnu-4.4.4-hardenednopie
 [6] x86_64-pc-linux-gnu-4.4.4-hardenednopiessp
 [7] x86_64-pc-linux-gnu-4.4.4-hardenednossp
 [8] x86_64-pc-linux-gnu-4.4.4-vanilla

HTH
Comment 71 7v5w7go9ub0o 2010-07-18 16:07:42 UTC
(In reply to comment #70)

[]

> 
> (ISTM there are "broken with hardened" concerns out there that simply no longer
> apply (e.g. lilo); perhaps this is one?)

Sorry..... another "e.g." that I might have mentioned is nvidia driver and settings. I presently have to 
rm /usr/portage/profiles/hardened/linux/amd64/mask* so that I can then compile mplayer/vdpau, nvidia custom drivers and settings using 4.4.4 vanilla (kernels are also compiled using vanilla). 

Subsequently compiling and running Mplayer with the full hardened compiler (and others, such as Suricata/cuda) with GPU support works fine.

HTH
Comment 72 Magnus Granberg gentoo-dev 2010-07-18 16:23:32 UTC
The probs we have is that we don't have any newer mplayer stable with the fixes in the tree and we still filter -fPIE -pie for x86.
And to get x86 fixed upstream will be hard. Amd64 works fine. Would love to close this bug and open new one with a patch that fix the x86 problem and it is okey upstream. Hope we can soon make a stablereq on a newer version mplayer with all the fixes.
Comment 73 Thomas Kucharczyk 2010-07-27 07:10:35 UTC
(In reply to comment #72)
> The probs we have is that we don't have any newer mplayer stable with the fixes
> in the tree and we still filter -fPIE -pie for x86.
> And to get x86 fixed upstream will be hard. Amd64 works fine. Would love to
> close this bug and open new one with a patch that fix the x86 problem and it is
> okey upstream. Hope we can soon make a stablereq on a newer version mplayer
> with all the fixes.
> 

Got this failure :/

http://gentoo.pastebin.ca/1909101
Comment 74 Reimar Döffinger 2010-07-29 08:15:07 UTC
The mplayer-1.0_rc4_p20091026-r1.ebuild misses the append-ldflags -nopie change, which causes that link failure.
And I still think that filter-flags -fPIC -fPIE behaves silly.
The newer ebuilds should work, and on 64 bit even give you a proper PIE binary.
Comment 75 Paul Goller 2010-09-26 13:08:53 UTC
This issue is still present on current amd64-hardened profile and the stable mplayer ebuild 1.0_rc4_p20091026-r1.
Comments in other bugs about this problem make me think, the mplayer devs are not going to make it PIE compatible soon.

I was able to compile mplayer with switching gcc profile to x86_64-pc-linux-gnu-4.3.4-hardenednopie:
# gcc-config -l
 [1] x86_64-pc-linux-gnu-4.3.4 *
 [2] x86_64-pc-linux-gnu-4.3.4-hardenednopie
 [3] x86_64-pc-linux-gnu-4.3.4-vanilla
# gcc-config 2
# env-update && source /etc/profile && emerge mplayer

What's the reason for not letting the ebuild do this or any other solution posted before?
Comment 76 Reimar Döffinger 2010-09-26 13:29:07 UTC
> Comments in other bugs about this problem make me think, the mplayer devs are
> not going to make it PIE compatible soon.

On everything except 32-bit x86 MPlayer is working perfectly with PIE (if not it should be possible to fix in no time)!
The stable ebuild is broken, unstable ebuild should work.
On 32-bit x86 PIE should work fine as well, but you _will_ get TEXTRELs unless you somehow disable all assembler code. This is the _only_ thing that will _not_ be fixed upstream, everything else is purely a Gentoo issue.
Comment 77 Paul Goller 2010-09-26 13:43:52 UTC
I didn't want to be rude to you mplayer guys.
I'm not able to follow the talking about assembler code and the differences on 32bit/64bit or anything else. I was just repeating some comment of another gentoo bug (... do not find the correct link... was too late and after too much research on that problem ;P ).

I am just confused about this problem being known since May 2005 and nobody is about to implement one of the fixes.
Comment 78 Xake 2010-09-26 14:18:54 UTC
(In reply to comment #75)
> This issue is still present on current amd64-hardened profile and the stable
> mplayer ebuild 1.0_rc4_p20091026-r1.
> Comments in other bugs about this problem make me think, the mplayer devs are
> not going to make it PIE compatible soon.
> 
Your problem is fixed in the mplayer-1.0_rc4_2010* ebuilds.
20100612 works fine for me.

(In reply to comment #77)
> I am just confused about this problem being known since May 2005 and nobody is
> about to implement one of the fixes.
> 

I am confused why this bug is still open.

Face it this bug has become an behemoth of all kinds of issues related to mplayer (and in the end ffmpeg).

Maybe time to just close this bug and start anew with a clean tracker depending on other bugs? Like the buildproblem in one bug, the textrels in one, people trying to play with an for hardened unsupported binary driver in another?

Currently this bug is a blurr of strange failures on different arches of various kind and nature.
Maybe after starting anew we may actually gradually be able to make all fixes/workarounds from this bug (which are often duplicates of other bugs already reported) enter the ebuilds one at a time, sending them to stable so this mess eventually gets sorted out?
Comment 79 Magnus Granberg gentoo-dev 2010-09-27 20:07:34 UTC
A working mplayer (mplayer-1.0_rc4_p20100612) have been in the tree for a long time now. Getting PIC friendly asm code on x86 would not happen upsteam i think.
On amd64 the asm code need to be PIC friendly in the libs so hardened works fine. Make a new bugreport if we still have hardened probs with newer mplayer in the tree.