On ia64, test-flags-CC -nopie returns true becuase -nopie is an unrecognized option that only generates a warning. flag-o-matic.eclass can be augmented with the following patch to catch this situation.
Created attachment 83180 [details, diff] patch to catch unrecognized options in test-flag-PROG
Created attachment 83181 [details, diff] updated patch The previous patch doesn't work because of a bash bug where the exit status is always zero when "local var=$(false)" is used instead of "var=$(false)". This patch moves the local declaration to a separate line to work around that problem.
Created attachment 83199 [details, diff] provide 'get-soft-flags' in flag-o-matic to determine flags for disabling hardened bits and bobs test-flags-CC has always only worked on the -f* options because gcc doesn't indicate an error return code for non-existent options that don't start with 'f'; not sure why - perhaps it may be worth raising upstream; gcc does fail in that it doesn't generate object files etc however returns 0 indicating all is well. BTW this isn't ia64-specific, and it's true for all gcc versions. -nopie is slightly special in that we add it as part of the piepatches, which aren't yet included in 4.x. Again this isn't an ia64-specific issue, but it is specific to gcc-4.x. It's best to avoid having "-nopie" (or "-nonow", "-norelro") explicitly anywhere in ebuilds (e.g. 'append-flags -nopie'), as -nopie is part of the hardened extensions to the compiler and it's useful to keep that abstracted in flag-o-matic if possible. The best way to get '-nopie' into CFLAGS/CXXFLAGS if you need it is via 'filter-flags -fPIE'. That ensures it only gets added if it's needed (and also valid). I do have a TODO item to add an interface to flag-o-matic that echoes flag settings necessary to disable the hardened tech, for use in variables other than CFLAGS/CXXFLAGS. Attached is the patch I currently have for that.
Kevin, your points are good regarding hardened flags, but IMHO my patch still makes sense for the general case. It doesn't hurt anything, hardly introduces any additional latency since it's just a bash comparison after the call to gcc, and allows the "unrecognized option" situation to be handled cleanly. I won't argue about it much, mostly because I don't care enough, but personally I think it would be worth adding.
Oh, I'm not against fixing test-flags-PROG - just I'd rather update flag-o-matic once, in particular to have the get-soft-flags() in place at the same time so there's no need for people to start adding 'test-flags-CC -nopie' all over the place. An additional point, on another bug (#127742) it's come to my attention we need to be careful about matching text output from gcc; if the locale is not English the match will fail as the error can be in Foreign. I think it's enough to stick 'LC_ALL= ' in front of ${PROG}, but since my gcc seems to be English only I don't have conclusive proof; I also need to check whether LC_ALL needs to be saved/restored or not. I'll run some more tests and then tomorrow (probably) commit the changes.
(In reply to comment #5) > I think it's enough to > stick 'LC_ALL= ' in front of ${PROG}, but since my gcc seems to be English only > I don't have conclusive proof; I also need to check whether LC_ALL needs to be > saved/restored or not. out=$(LC_ALL=C ${PROG} ...) I can tell you: First, this is correct (use C not blank). Second, you don't need to worry about saving/restoring, this Bourne shell syntax sets LC_ALL purely in the environment of the executed program.
Thanks - I'd picked up I needed something and was going to go for 'en'; but C makes more sense (I'll do the same on bug #127742). I worried about the save/restore because I've had trouble with IFS in this regard; but thinking about it that was probably because I was just doing an assigment rather than executing something: IFS="," fields=(${line}) leaves IFS as "," for subsequent commands in a script.
(In reply to comment #3) > test-flags-CC has always only worked on the -f* options because gcc doesn't > indicate an error return code for non-existent options that don't start with > 'f'; not sure why - perhaps it may be worth raising upstream; gcc does fail in > that it doesn't generate object files etc however returns 0 indicating all is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > well. This turns out to be incorrect, don't know why I thought it. For options that are not recognised by any of the subprograms (which is the case for '-nopie'), the compiler driver issues the warning to stderr but continues anyway with no problem. So there should be no need to change test-flag-PROG, as it shouldn't be causing problems. Aron, could you describe the situation that actually causes a problem? I'm guessing it's something to do with ghc, but if I understand correctly even there it should be ok because it's still just a string on stderr with return code 0 (unless ghc requires stderr from gcc to be empty). BTW I noticed <gcc-4 and >=gcc-4 generate the warnings differently; <gcc-4 says: ...option `-nopie' but >=gcc-4 says: ...option '-nopie' (different opening quote mark). I have a version of the patch that deals with that.
(In reply to comment #8) > Aron, could you describe the situation that actually causes a problem? I'm > guessing it's something to do with ghc, but if I understand correctly even > there it should be ok because it's still just a string on stderr with return > code 0 (unless ghc requires stderr from gcc to be empty). Well it's more of an annoyance than a problem per-se. It jsut means that the build log will have that warning every time ghc compiles something. That's not so bad, but we bake these flags into the ghc driver script so it means the user would get that warning every time they compiled, or linked anything. Of course we can put in a special excpetion for the -nopie flag on ia64 (& probably ppc-osx too) but if it just worked that'd be nice. Summary: it's more a question of taste, we can work around it.
It's not ia64-specific. Indeed the ia64 version of gcc should normally have the -nopie flag in its specs the same as other arches. Situations where you don't get pie are (as far as I can tell): 1) building gcc with USE=nopie 2) old versions of gcc (pre 3.3) 3) gcc-4.1.0 (still -*) If we provide the get-unharden-flags function (more boring but a better name than get-soft-flags), then ghc won't have to use test-flags-CC at all anyway. With regards the ghc driver, since the flags are baked in when the compiler is built, if you subsequently switch to a different version of gcc (either upgrade or gcc-config) and that different version doesn't support -nopie, the warnings are going to start appearing anyway. Having said that, there's not much you can do here short of running the test in the driver which isn't very nice. Another option is to muck around with the environment variable GCC_SPECS; I'll have a think and get back to you on that one. Just for kicks you could try: gcc_install_dir=$(gcc -print-search-dirs | awk '$1=="install:" {print $2}') [[ -z ${GCC_SPECS} && -f ${gcc_install_dir}/hardenednopiessp.specs ]] && export GCC_SPECS=${gcc_install_dir}/hardenednopiessp.specs in the driver before invoking ghc (and remove the extra -optc-nopie etc).
(from IRC discussion) For the case of ghc, which is currently unique, a further problem is that baking the options into the wrapper script means they can be incorrect if gcc is later switched to a version that doesn't support the flags. Suggest instead checking dynamically in the wrapper (driver): force_vanilla="" gccinst=$(gcc -print-search-dirs |\ awk '$1=="install:" { print $2}') [[ -f ${gccinst}/vanilla.specs ]] && \ force_vanilla="-specs=\"${gccinst}/vanilla.specs\"" ... -optc${force_vanilla} ... May also need -optl${force_vanilla} if ghc doesn't pass -optc stuff to gcc when invoking gcc for linking.
you'll need to set LC_ALL=C in the ${PROG} env otherwise the translated strings may not match "unrecognized option"
What's going on here? Has this been fixed? Put on hold?
Reassigning due to retirement
Nothing has happened here for quite a few years. Has this been fixed? Not an issue anymore?
