Both of these components suffer from the same compilation time error which looks like that: i686-pc-linux-gnu-g++ -O2 -march=pentium4 -fstack-protector -c vmac.cpp vmac.cpp: In member function `void CryptoPP::VMAC_Base::VHASH_Update_SSE2(const CryptoPP::word64*, size_t, int)': vmac.cpp:367: error: can't find a register in class `GENERAL_REGS' while reloading `asm' make: *** [vmac.o] Error 1 I've found this message: http://groups.google.pl/group/linux.gentoo.user/browse_thread/thread/45f5242a2837d1e/e4489e3033682915?lnk=st&q=gentoo+error%3A+can%27t+find+a+register+in+class+%60GENERAL_REGS%27+while+reloading+%60asm%27#e4489e3033682915 This suggests these packages will never be able to be compiled in hardened profile and therefore both should be masked. Since latest amule daemon uses crypto++, latest version of amule should also be masked! Reproducible: Always Steps to Reproduce: 1. Install hardened gentoo with SSP 2. emerge --sync 3. emerge crypto++ amule mplayer Actual Results: i686-pc-linux-gnu-g++ -O2 -march=pentium4 -fstack-protector -c vmac.cpp vmac.cpp: In member function `void CryptoPP::VMAC_Base::VHASH_Update_SSE2(const CryptoPP::word64*, size_t, int)': vmac.cpp:367: error: can't find a register in class `GENERAL_REGS' while reloading `asm' make: *** [vmac.o] Error 1 Expected Results: merged packages
mplayer works fine @ runtime on hardened given mprotect is not enforced on the binary. Concerning compile, a simple workaround is to compile with nopie gcc specs profile. Yeah it smells, but these aren't the only packages needing this workaround, so we might as well mask all the others too if this is the road to be traveled. Therefore I would vote against masking and resolve as WONTFIX/INVLAID or a duplicate of one of the following bugs: bug 93862, bug 133586, bug 175627 or bug 184003 A separate bug should be opened for the fixing of crypto++. If it lingers forever too then so be it.
mplayer will never be p.masked in hardened profiles
mplayer compile time bug (hardened profile): i686-pc-linux-gnu-gcc -I../libavcodec -I../libavformat -Wdisabled-optimization -Wdeclaration-after-statement -I. -I.. -I../libavutil -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -march=pentium4 -mtune=pentium4 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/X11R6/include -I/usr/include/ -I/usr/include/SDL -D_REENTRANT -I/usr/include/freetype2 -I/usr/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -c -o vf_decimate.o vf_decimate.c vf_decimate.c: In function `diff_MMX': vf_decimate.c:26: error: can't find a register in class `BREG' while reloading `asm' make[1]: *** [vf_decimate.o] Error 1 make[1]: Leaving directory `/tmp/portage/media-video/mplayer-1.0_rc2_p25993/work/mplayer-1.0_rc2_p25993/libmpcodecs' make: *** [libmpcodecs/libmpcodecs.a] Error 2 compile time flags were: USE="X a52 aac aalib alsa amrnb amrwb bidi bl cdparanoia dga dts dv enca encode esd ftp ggi gif gtk iconv ipv6 jack jpeg ladspa libcaca live lzo mad md5sum mmx mp2 mp3 musepack nas openal opengl oss png pnm quicktime rar real sdl speex srt sse sse2 tga theora tivo truetype unicode vidix vorbis win32codecs x264 xanim xv xvid xvmc -3dnow -3dnowext (-altivec) -arts -bindist -cddb -cdio -cpudetection -custom-cflags -debug -directfb -doc -dvb -dvd -fbcon -joystick -lirc -livecd -mmxext -nemesi -pulseaudio -radio -rtc -samba (-ssse3) -svga -teletext -v4l -v4l2 -xinerama -xscreensaver -zoran" VIDEO_CARDS="-mga -s3virge -tdfx -vesa" With USE="-mmx -sse -sse2" compilation stops in different place: i686-pc-linux-gnu-gcc -I../libswscale -I../libavcodec -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I.. -I.. -I../libavutil -Wdisabled-optimization -Wdeclaration-after-statement -I. -I.. -I../libavutil -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -march=pentium4 -mtune=pentium4 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/X11R6/include -I/usr/include/ -I/usr/include/SDL -D_REENTRANT -I/usr/include/freetype2 -I/usr/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -c -o h264.o h264.c cabac.h: In function `get_cabac_noinline': cabac.h:529: error: PIC register `%ebx' clobbered in `asm' make[1]: *** [h264.o] Error 1 make[1]: Leaving directory `/tmp/portage/media-video/mplayer-1.0_rc2_p25993/work/mplayer-1.0_rc2_p25993/libavcodec' make: *** [libavcodec/libavcodec.a] Error 2 So I've tested also USE="-mmx -sse -sse2 -x264" but no change, still it tries to compile h264.c which ends with error in cabac.h
The workaround is to switch to hardenednopie gcc specs, compile, then switch back.
The crypto++ issue is already the subject of bug 215211. Furthermore, the mplayer issue is the subject of bug 175627. But this bug isn't merely reporting issues, it's issuing a request to package.mask the affected packages. In that light, I see no choice but to close this as CANTFIX ("is not solvable in any reasonable fashion") because the hardened team will clearly never honour such a request on the basis that it is not reasonable. The explanation for this is simple: "we don't mask everything when it does not build. We try and fix the things that are worth fixing". In other words, if we package.mask everything that requires a workaround (or simply integrate compile hacks such as "-fno-PIC") then we are de-incentivising people to actually fix these issues in the most technically correct manner. On the other hand, we are well aware that it is an inconvenience to have to use workarounds until things actually are fixed. I can only suggest that the author use a custom eclass in an overlay or a custom .bashrc in order to automatically disable PIC for the affected package(s). This is the route that some other users have taken, as evidenced by http://bugs.gentoo.org/show_bug.cgi?id=175627. Any contributions in terms of resolving the incompatibilities with PIC should go to the relevant bugs themselves, as noted above.
Also see bug #217907 ...
