ar: creating libmenu.a /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../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.20060415 failed. # emerge -pv mplayer [ebuild N ] media-video/mplayer-1.0.20060415 (-3dfx) (-3dnow) -3dnowext -X -aac -aalib -alsa (-altivec) -arts -bidi +bindist -bl -cdparanoia -cpudetection -custom-cflags -debug -dga -directfb -doc -dts -dv -dvb -dvd -dvdread -edl -encode -esd -fbcon -ggi -gif -gtk -i8x0 -ipv6 -jack -joystick +jpeg (-libcaca) -lirc -live -livecd -lzo -mad -matroska -matrox (-mmx) (-mmxext) -musepack -nas -nvidia -openal -opengl -oss +png (-real) -rtc -samba -sdl -speex (-sse) (-sse2) (-svga) -tga -theora -truetype -unicode -v4l -v4l2 +vorbis (-win32codecs) -x264 -xanim -xinerama -xmms -xv -xvid -xvmc 0 kB # emerge info Portage 2.0.54-r2 (hardened/amd64/multilib, gcc-3.4.5, glibc-2.3.6-r3, 2.6.13-hardened-r1 x86_64) ================================================================= System uname: 2.6.13-hardened-r1 x86_64 AMD Opteron(tm) Processor 842 Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 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="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -fforce-addr" 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 /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -fforce-addr" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg distclean distlocks nodoc noinfo sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j4 --quiet" PKGDIR="/usr/portage/local/hardened-multilib" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 berkdb bindist boundschecking bzip2 cgi cli crypt dlloader hardened jpeg justify mp3 mpeg ogg pam pic png readline session snmp ssl sysfs tiff userlocales vcd vorbis xml xml2 zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS
This bug is over half a year old. Do you still experience the same problem with mplayer 1.0_rc1-r2?
Yes. The problem comes from use of the hardened compiler in combination with line 383 of libvo/osd_template.c: "paddb "MANGLE(bFF)", %%mm2\n\t" where bFF is a static constant 0xFFFFFFFFFFFFFFFFULL - so that instruction generates non-PIC code in order to reference the constant. It could be patched to avoid it, but perhaps it's just simpler just to 'filter-flags -fPIE' also on amd64 (which means mplayer doesn't get ASLR protection, same as on x86).
Created attachment 108916 [details, diff] Allow compiler to determine relocation type, rather than forcing a non-PIC type This replaces: paddb "MANGLE(bFF)", %%mm2 which forces non-PIC code, with paddb %3, %%mm2 ... :: ..., "m" (bFF) which allows the compiler to generate what it thinks is best, depending on how the object is built. I think it's correct, but it could do with review. However, this just exposes the next problem of the same type, in libmpcodxs/vf_fspp.c. In fact, the code is littered with this kind of non-PIC-only assembler (just grep for 'MANGLE('). Previously upstream haven't been particularly amenable to accepting patches for this kind of thing, as their primary concern is speed, not suitability for building PIEs.
ok; had a quick chat with blubb, and we agree the best thing to do is to filter-flags -fPIE also for amd64. media-video - currently you filter-flags -fPIE on x86, only if use custom-cflags. Could you change this behaviour, and do 'filter-flags -fPIE' always, after that part - i.e. even if not custom-cflags? (patch to follow, for clarity).
Created attachment 108946 [details, diff] Filter -fPIE always, in ebuild
I do not think this is the correct solution. You are blindly filtering pie on arches in which pie may actually have no problems. If mplayer cant handle it for x86/x86_64 then please limit the filtering on those arches only.
Well, I did consider it, but since we only PIE on x86, amd64 and ppc I figured it wasn't worth the bother. Still, conditional on use x86 || use amd64 is simple enough to do. Another alternative is to switch off all the accelerated mmx/sse etc asm when 'use hardened'. Either of those solutions would be fine as far as I'm concerned.
(In reply to comment #7) > Well, I did consider it, but since we only PIE on x86, amd64 and ppc I figured > Another alternative is to switch off all the accelerated mmx/sse etc asm when > 'use hardened'. Please don't key turning off pic stuff when using a hardened toolchain based on the hardened use flag. If something needs pic love then USE=pic seems a better choice. I notice many new users on IRC seem to think that when they see USE=hardened it somehow improves the security on a given package and thus try to enable it. Personally I'd like to get away from using USE=hardened on most of the tree (for nearly everything but gcc itself) when USE=pic should be used (asterisk/xorg/glib come to mind). Now if the only problem with mplayer on amd64 arches is some OSD plugin then don't you think a better option might be to disable that plugin itself vs losing these protections all together? I mean like your client www browsers and media viewing apps are often the ones that we see the most of in GLSA's
ISTR being advised against using USE=pic for this sort of thing before, but perhaps my memory is playing up. I haven't tried anything other than USE="jpeg vorbis" on amd64, when reproducing the issue reported in the first place, and as I indicated above after clearing the vorbis one, it just trips elsewhere anyway. To see what else might be affected, from the mplayer working directory I did: find . | xargs grep -l '^[^#]*MANGLE(' ./libpostproc/postprocess_template.c ./libmpcodecs/vf_fspp.c ./libvo/osd_template.c ./libswscale/swscale_template.c ./libswscale/rgb2rgb_template.c ./libswscale/yuv2rgb_template.c ./libavcodec/i386/motion_est_mmx.c ./libavcodec/i386/simple_idct_mmx.c ./libavcodec/i386/dsputil_mmx.c ./libavcodec/cabac.h ./liba52/liba52_changes.diff ./liba52/resample_mmx.c ./liba52/imdct.c ./mp3lib/dct64_MMX.c ./mp3lib/decode_i586.c ./mp3lib/dct64_3dnow.c ./mp3lib/tabinit_MMX.c ./mp3lib/dct36_3dnow.c ./mp3lib/decode_MMX.c ./mp3lib/dct64_k7.c and guessing most of those get used on amd64 and would similarly fail, it's clear removing those parts pretty much guts mplayer. Hence my suggestion to either switch off pie completely for it, or (better for security, certainly) switch off the assembler stuff and fall back to the non-optimised C implementations (--disable-mmx etc).
*** Bug 218566 has been marked as a duplicate of this bug. ***
No one with a hardened toolchain has been able to compile mplayer in over a year? It looks like there are one or more solutions suggested here. Implementation?
*** Bug 224871 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 93862 ***
