has_pic() ... test_version_info pie ## returns 0 instead of 1 ... has_pie() ## returns 1 Portage 2.0.51.19 (default-linux/x86/2005.0/2.4, gcc-3.4.3-20050110, glibc-2.3.4.20040808-r1, 2.4.28-gentoo-r7 i686) ================================================================= System uname: 2.4.28-gentoo-r7 i686 AMD Duron(tm) Processor Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 7 2005, 14:49:57)] distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.4.22-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -pipe -fforce-addr -fmove-all-movables -mfpmath=sse,387" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /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/lib/mozilla/defaults/pref /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 /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe -fforce-addr -fmove-all-movables -mfpmath=sse,387" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache cvs distlocks fixpackages keeptemp keepwork noclean nostrip sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo ftp://ftp.berlios.de/pub/gentoo-deutsch http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="de_DE@euro" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex X X509 Xaw3d aalib acl acpi acpi4linux activefilter alsa antlr apache1 apm arts artswrappersuid auctex audiofile avi bash-completion bcel berkdb bitmap-fonts cddb cdparanoia cdr chroot clisp cmucl crypt cscope cups curl devmap dga directfb divx4linux dnd doc dv dvb dvd dvdr editor edl emacs emboss encode ext-png ext-zlib faad fam fbcon firebird flac fltk foomaticdb foreign-package fortran gcj gcl gd gdbm ggi gif gimpprint glut gphoto2 gpm graphviz gstreamer gtk2 hbci idl imagemagick imap imlib innodb jack jack-tmpfs java javamail javascript jbig jce jdepend jpeg jsch junit kde ladcca lcms ldap lesstif libcaca libg++ libwww lirc live lm_sensors log4j ltsp lzo mad maildir matroska mbox md5sum mikmod mmx mng monkey mozilla moznocompose moznoirc moznomail mozsvg mp3 mpeg mupad-noscilab mysql nas ncurses network nls oav ogg oggvorbis openal opengl oss pam pcap pdflib perl pg-hier php physfs plotutils png pnp postgres ppds python qt quicktime readline real regexp rtc ruby samba sasl scanner sdl skey slang slp snmp sox speex spell sqlite sse ssl svg svga tcpd tetex theora tiff transcode truetype truetype-fonts type1-fonts usb vim-with-x vorbis win32codecs wmf xalan xerces xine xml2 xv xvid yaz zeo zlib linguas_de" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS
Looks to me like the "test_version_info pie.." line went to the wrong function (possibly patch hunk position misalignment automatically "fixed"). Of course, if it moves to has_pie() it'll just transfer the problem to there. It'd be interesting to know what has_hardened() does on a non-hardened system; I have a suspicion it may always return 0. IMO these functions should not be used. There is persistent confusion about what they are supposed to do - for example whether has_pic() indicates the compiler is generating PIC with current CFLAGS or whether it simply supports -fPIC et. al. It doesn't help that there's no header comment at the top of the eclass. In general use flags should be used in ebuilds rather than these has_pic/pie/ssp/hardened() functions. I suggested a while back these functions could be deprecated and put some effort into eliminating them from the few places where they were being used at the time, but that appears to be a losing battle as their use has proliferated.
There are several things that would cause the compiler to build with pie and stack_smash_protect that goes beyond just a simple check to see if a use flag is in effect. While a use flag was often a good indicator of this, checking the gcc compiler itself to see if it understood certain command-line options was the only definite way of seeing what the compiler actually supports. As the indicators and gcc version strings changed over time, but the need for some way to find out *if* the compiler was turning on pic/pie/ssp by default (and have the ebuilds then react accordingly), these tests were moved to has_pic, has_pie, and so forth, as editing dozens of ebuilds to update their method of identifying this condition in order to disable sloppy inline assembler or whatever the real underlying compatibilty issue happened to be, was just plain silly. That is your history lesson for the day. Enjoy.
Scott: test_version_info pie ## returns 0, has_pie() ## returns 1 - A second lesson, please.
Created attachment 57413 [details, diff] Fixup has_pic, has_pie, add has_ssp_all This patch removes the stray test_version_info call from has_pic(); test_version_info doesn't tell you anything about whether the option is on or not, only whether it is available, so has no place in these functions IMO. The patch provides an implementation of has_pie() which I think will work. It does this by building an exe and cheking its ELF type; there's no other reliable way of working this out that I can see. It also provides a new 'has_ssp_all' function which would be useful for the mozilla ebuilds, and any others that need to downgrade -fstack-protector-all to -fstack-protector. There are also new descriptions to the header to help avoid future confusion. I think these functions are badly named; "builds_pic", "builds_pie", "builds_ssp" and "builds_ssp_all" would be better for example - I don't know how painful it would be to change. has_hardened() is an anomaly; I can't see that it's useful; mainly because it's far from clear what it means. I don't know if gcc includes "Hardened" in its version string when built without use=hardened; if it does then this function always returns true, if it doesn't then this function is equivalent to 'use hardened' (since the compiler version string doesn't change with the gcc-config selected compiler). It begs the question, what is the function for? The only other thing I can think of that isn't covered by the other functions, is -z,now - in which case perhaps a 'has_znow (builds_znow)' function might be worth considering instead of has_hardened.
One could build an entire system without ever using the "hardened" use flag either by not knowing it was there or whatever other reason, though they added "-fPIC" or "-fstack-protector" into their CFLAGS. However these pic/pie/ssp options got set, whether it was by building hardened-gcc which activated these by default, by building regular gcc and choosing an alternate set of specs with the gcc-config tool, or by adding various options into their CFLAGS... there are pieces of code (pic-unfriendly inline assembler was one of the bigger trouble spots) in sources that required special handling. "filter-flags", in addition to just plain filtering flags, if it was asked to filter out something related to pic/pie/ssp it also added cflags that would negate the features. If it was told to "filter-flags -fstack-protector", it would not only filter that flag, but would add "-fno-stack-protector" and "-fno-stack-protector-all", and so on, to forcibly deactivate a feature no matter how it had been activated in the first place. "has_ssp" should therefore respond true (as far as bash is concerned) if ssp would be active in something built by gcc, no matter which method actually did the activating. filter-flags can safely be called without this test, but think of it along these lines: has_ssp && filter-flags "-fstack-protector" has_pie && do_something_to_fix_pie_handling has_pic && filter-flags "-fPIC" Troublesome non-pic-friendly inline assembler was often only included by (upstream) packages if they were ./configured to enable mmx, so ebuilds could work around that by disabling those pieces, perhaps like so: has_pic && MYCONF="${MYCONF} --without-mmx" Return codes in bash tend to be the opposite of what humans expect, but if you do this next line and it prints the output, then the test worked just fine: has_something && echo '"something" is in effect' That is, if that "something" actually was in effect. The "Hardened" in the gcc banner only gets added if gcc was built with use=hardened, however with the profile switching from gcc-config, its perhaps no longer an accurate test. Maybe having gcc-config add some environment variable (to be set when /etc/profile is sourced) that would be tested instead of reading gcc's banner would be a reasonable change. Not quite sure. But its not a guarantee that merely not having the "hardened" use flag active on your system means none of these tests can come back with a positive result.
>However these pic/pie/ssp options got set, whether it was by building hardened-gcc which activated these by default, by building regular gcc and choosing an alternate set of specs with the gcc-config tool, or by adding various options into their CFLAGS... I'm not into this hardened stuff as I would like, but I'm somewhat sure not to have enabled such a flag and never built anything with the hardened use flag enabled on this box. The possibilities you're listing do all not apply.
Hm, somewhat irritating when you're not so much interested into this compiler stuff. So has_pic() results to 1 because my gcc has pie support despite you know if -FPIE will be used at all? Why does this make any sense?
s/know/don't know/
If I may chime in. seems has_pie is broke and thats what this bug seems to be about. The proposed patch I really do not like. I at all costs want avoid disk file i/o has_hardened can go as far as I care. removing the test_version_info pie check from has_pic is fine with me..
Created attachment 57511 [details, diff] Fixip just has_pic, add has_ssp_all and header comments Same patch, without the has_pie() changes. FWIW the has_pie() implementation I proposed previously was inspired by the has_m32()/has_m64() functions in the same eclass.
patch from comment #10 added to flag-o-matic.eclass
fixed - but see also bug #100974
