# emerge -pv media-video/mjpegtools These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-video/mjpegtools-1.9.0 USE="X dga dv png sdl yv12 -gtk (-mmx*) -quicktime -v4l" 0 kB ... x86_64-pc-linux-gnu-gcc -fno-PIC -march=athlon64 -O2 -pipe -fomit-frame-pointer -fno-strict-aliasing -pthread -Wall -Wunused -o .libs/yuvscaler yuvscaler-yuvscaler.o yuvscaler-yuvscaler_resample.o yuvscaler-yuvscaler_bicubic.o ../utils/.libs/libmjpegutils.so -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld: yuvscaler-yuvscaler.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC yuvscaler-yuvscaler.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [yuvscaler] Error 1 make[2]: Leaving directory `/var/tmp/portage/media-video/mjpegtools-1.9.0/work/mjpegtools-1.9.0/yuvscaler' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/media-video/mjpegtools-1.9.0/work/mjpegtools-1.9.0' make: *** [all] Error 2 * * ERROR: media-video/mjpegtools-1.9.0 failed. * Call stack: * ebuild.sh, line 48: Called src_compile * environment, line 2752: Called die * The specific snippet of code: * emake || die "emake failed"; * The die message: * emake failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/media-video/mjpegtools-1.9.0/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/media-video/mjpegtools-1.9.0/temp/environment'. * >>> Failed to emerge media-video/mjpegtools-1.9.0
Created attachment 189797 [details] emerge --info
Created attachment 199597 [details, diff] proposed patch fixing PIC compilation problem It seems that it is compiled using -fno-pic for both x86 and amd64. I've removed it and it compiles fine but I'm not sure if this the right way to do - maybe it was supposed to be no-pic? Can it cause some runtime errors? Could somebody more knowledgeable review this please? ;) It fails on amd64 only, on x86 it creates TEXTREL instead. This patch attempts to fix them both.
*** Bug 325791 has been marked as a duplicate of this bug. ***
Works fine for me. Even with the -fno-PIC fix. media-video/mjpegtools-1.9.0-r1 USE="X dga dv png sdl yv12 -gtk -mmx -quicktime -v4l" jasmin ~ # emerge --info Portage 2.2_rc67 (hardened/linux/amd64/10.0, gcc-4.4.4, glibc-2.11.2-r0, 2.6.32-hardened-r4 x86_64) ================================================================= System uname: Linux-2.6.32-hardened-r4-x86_64-Intel-R-_Xeon-R-_CPU_E5420_@_2.50GHz-with-gentoo-2.0.1 Timestamp of tree: Sun, 27 Jun 2010 18:45:01 +0000 app-shells/bash: 4.1_p7 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-util/cmake: 2.8.1-r1 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.65-r1 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 virtual/os-headers: 2.6.34 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=core2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=core2" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="-kbD --binpkg-respect-use=y --fail-clean=True" FEATURES="assume-digests distlocks fail-clean fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.sunet.se/pub/Linux/distributions/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LDFLAGS="-Wl,-O1" MAKEOPTS="-j15"
media-video/mjpegtools-1.9.0-r1 USE="mmx -X -dga -dv -gtk -png -quicktime -sdl -v4l -yv12" with the remove -fno-PIC fix it compiles fine on x86 and x86_64 with mmx use flag enable. @madia-video madia-tv do the fix work for you too? If it works okay to commit the fix?
I can confirm that the tools compile with this patch and the tested binaries are at least runnable. I haven't verified the results for now. amd64, hardened, gcc 4.3.5 p1.0, pie-10.1.5
I also confirm that patch allows mjpeg-1.9.0 to build on hardened amd64 Thanks Portage 2.1.8.3 (hardened/linux/amd64/10.0, gcc-4.3.4, glibc-2.11.2-r0, 2.6.32-gentoo-r7 x86_64) ================================================================= System uname: Linux-2.6.32-gentoo-r7-x86_64-AMD_Turion-tm-_64_X2_Mobile_Technology_TL-56-with-gentoo-2.0.1 Timestamp of tree: Sat, 07 Aug 2010 12:30:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.11 dev-lang/python: 2.5.4-r3, 2.6.5-r2, 3.1.2-r3 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.5.2-r2 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8-sse3 -O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=k8-sse3 -O2" DISTDIR="/usr/local/tmp/portage/distfiles" FEATURES="assume-digests collision-protect distlocks fixpackages multilib-strict news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.cambrium.nl/pub/os/linux/gentoo/ http://gd.tuwien.ac.at/opsys/linux/gentoo/" LANG="pt_PT.utf-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en pt pt_PT" MAKEOPTS="-j4" PKGDIR="/usr/local/tmp/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/usr/local/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/gentoo/gentoo-x86" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac acpi akonadi alsa amd64 amr amrnb amrwb applet artworkextra aspell autotrace avahi bash-completion beagle blas branding bzip2 cairo cdda cdrkit chm cleartype cli compiz-fusion cracklib crypt cups cxx dbus deskbar devhelp dia divx djvu dts dvd dvdr dvdread dvi ebook eds emerald enca encode epiphany exif ffmpeg fftw firefox flac fuse gd gdbm gdu gedit gif gimp glade glib glitz glut gmedia gnome gnome-keyring gnome-print gnutls gphoto2 graphviz gs gsf gstreamer gtk gtkspell hal hardened hddtemp hyperestraier iconv ieee1394 imagemagick imlib inotify insecure-savers jack javascript jpeg jpeg2k justify kipi kqemu ladspa lame lapack laptop latex lcms libcaca libnotify libsexy libwww mad matroska mecab mikmod mmap mmx mmxext mng modules mp2 mp3 mp4 mpeg mplayer mudflap multilib musepack musicbrainz mysql nautilus ncurses networkmanager nls nptl nptlonly offensive ogg openal openexr opengl openmp oss4 otr pam pango pcre pdf pic plasma png policykit pppd python quicktime readline realmedia reflection rtsp samba sdl sdl-image semantic-desktop session smp sndfile sound sourceview sox speex spell spl sqlite srt sse sse2 ssl stream svg sysfs syslog system-sqlite t1lib taglib tcpd theora threads tiff tracker truetype twolame type1 unicode urandom usb v4l v4l2 vdpau vhosts vim-syntax vorbis wavpack webkit wifi wmp x264 xcb xcomposite xfs xhtml xinerama xorg xosd xpm xscreensaver xulrunner xv xvid xvmc zeroconf zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="*" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev synaptics joystick" KERNEL="linux" LCD_DEVICES="xosd" LINGUAS="en pt pt_PT" QEMU_SOFTMMU_TARGETS="arm i386 mips mips64 mips64el mipsel x86_64" QEMU_USER_TARGETS="arm armeb i386 mips mipsel x86_64" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nv nvidia none" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 360788 [details, diff] yuvscaler pic Can anybody please test if this still happens with mjpegtools-2.1.0. I can add the patch but I will ask upstream first if there is any special reason to compile with -fno-pic. Does the attached patch (removing yuvscaler_CFLAGS=@PROGRAM_NOPIC@ from yuvscaler/Makefile.am) work as well? configure.ac however states that compute bound programs should not use pic code because this is slower.
(In reply to Daniel Pielmeier from comment #8) > Created attachment 360788 [details, diff] [details, diff] > yuvscaler pic > > Can anybody please test if this still happens with mjpegtools-2.1.0. I can > add the patch but I will ask upstream first if there is any special reason > to compile with -fno-pic. > > Does the attached patch (removing yuvscaler_CFLAGS=@PROGRAM_NOPIC@ from > yuvscaler/Makefile.am) work as well? configure.ac however states that > compute bound programs should not use pic code because this is slower. PIC code will be slower on x86 but on amd64 it will be in the error margin and the libs need to be compile with PIC.
yuvscaler_CFLAGS=@PROGRAM_NOPIC@ fix the build error but i still see -fno-PIC in the build.
Created attachment 363900 [details, diff] yuvscaler pic 2 (In reply to Magnus Granberg from comment #10) > yuvscaler_CFLAGS=@PROGRAM_NOPIC@ fix the build error but i still see -fno-PIC > in the build. But not for yuvscaler I hope? This is because the first patch globally disables -fno-PIC. My patch is less intrusive and only disables it for yuvscaler which is were the build failure on hardened occurs. From your comment #5 I read that the build failure occurs on both x86 and x84_64 hardened? If using PIC code on x86_64 has no drawbacks but on x86 the code will be slower the best solution would be probably to remove -fno-PIC from x86_64 globally but only locally for yuvscaler on x86. So everything else which causes no PIC related build errors can still use -fno-PIC to have the speed advantage. Attached is an updated patch which should do the trick.
(In reply to Daniel Pielmeier from comment #11) > Created attachment 363900 [details, diff] [details, diff] > yuvscaler pic 2 > > (In reply to Magnus Granberg from comment #10) > > yuvscaler_CFLAGS=@PROGRAM_NOPIC@ fix the build error but i still see -fno-PIC > > in the build. > > But not for yuvscaler I hope? > > This is because the first patch globally disables -fno-PIC. My patch is less > intrusive and only disables it for yuvscaler which is were the build failure > on hardened occurs. From your comment #5 I read that the build failure > occurs on both x86 and x84_64 hardened? It fail on x86_64 and on x86 it make textrel and get kill by the hardened kernel > > If using PIC code on x86_64 has no drawbacks but on x86 the code will be > slower the best solution would be probably to remove -fno-PIC from x86_64 > globally but only locally for yuvscaler on x86. So everything else which > causes no PIC related build errors can still use -fno-PIC to have the speed > advantage. > > Attached is an updated patch which should do the trick. If it works is okay with me.
(In reply to Magnus Granberg from comment #12) > > > > > This is because the first patch globally disables -fno-PIC. My patch is less > > intrusive and only disables it for yuvscaler which is were the build failure > > on hardened occurs. From your comment #5 I read that the build failure > > occurs on both x86 and x84_64 hardened? > It fail on x86_64 and on x86 it make textrel and get kill by the hardened > kernel > > > > If using PIC code on x86_64 has no drawbacks but on x86 the code will be > > slower the best solution would be probably to remove -fno-PIC from x86_64 > > globally but only locally for yuvscaler on x86. So everything else which > > causes no PIC related build errors can still use -fno-PIC to have the speed > > advantage. > > > > Attached is an updated patch which should do the trick. > If it works is okay with me. Well I can not test this as I have no hardened system. It is okay for normal amd64 here. If there are no problems on hardened x86 for the other parts of mjpegtools which use -fno-PIC I can apply the patch in the meantime. However I think this does not fix the underlying bug. So I have opened a bug upstream at mjpegtools sourceforge tracker. It would be great if you could add some information there about what parts of the hardened features cause the build failure respectively the runtime abortion.
+*mjpegtools-2.1.0-r1 (30 Nov 2013) + + 30 Nov 2013; Daniel Pielmeier <billie@gentoo.org> + +mjpegtools-2.1.0-r1.ebuild, +files/mjpegtools-2.1.0-pic.patch: + Disable -fno_PIC. This fixes bug #267829. Thanks to a_tevelev for the report. Upstream removed building with -fno_PIC completely.
