GCC allows values to be separated by flags with spaces. But test-flags-PROG fails to handle this and checks options one by one which leads to dropping flags that require a value. For example, CFLAGS="-isysroot /cross" getting transformed into CFLAGS="/cross" There are many other similar options like -idirafter, -include, -imacros, -iprefix, -isystem, -imultilib, -isysroot and many more. The possible workaround is to omit spaces between a flag and its value, thanks to GCC that supports this. Reproducible: Always Steps to Reproduce: 1. CFLAGS="-isysroot /cross" 2. emerge any package Actual Results: Compilation fails due to clobbered CFLAGS. Expected Results: CFLAGS doesn't get corrupted and compilation succeeds.
"GCC allows values to be separated from flags with spaces." instead of "GCC allows values to be separated by flags with spaces." Sorry for the typo.
there's no way to handle this in $CFLAGS without hardcoding specific flags. however, i can't see how any of these flags you reference being in user make.conf. they should never be there. so unless you have a realistic example, i'm inclined to just punt this.
I think only commands that take a path break compilation. For something like --param l1-cache-line-size=64 I know both get parts get stripped.
(In reply to comment #2) > there's no way to handle this in $CFLAGS without hardcoding specific flags. > however, i can't see how any of these flags you reference being in user > make.conf. they should never be there. If a flag gets rejected by the compiler, we could test it with the next flag before throwing it away. But I'm afraid, this could possibly harm more than help (although I don't have any example for such breakage). > so unless you have a realistic example, i'm inclined to just punt this. The only example I can come up with (besides Ryan's "--param l1-cache-line-size=64" example) is something like "-Wl,-z -Wl,now" which could also break while testing flags one by one. (fortunately, gcc accepts "-Wl,-z" and nothing breaks in this particular case)
the -Wl flags are already fairly funky (there's more ways to pass things to the linker than what you've found). my opinion there is to stop monkeying around and use -Wl,-z,now. attempting to handle further split or merged linker flags isn't really useful.
-Wl flags shouldn't be going through test-flags-PROG anyways.
(In reply to comment #5) > the -Wl flags are already fairly funky (there's more ways to pass things to the > linker than what you've found). my opinion there is to stop monkeying around > and use -Wl,-z,now. attempting to handle further split or merged linker flags > isn't really useful. While it's possible to pass "-Wl,-z -Wl,now" as "-Wl,-z,now", the current flag-o-matic.eclass behavior will silently clobber similar user's flags (which are in fact supported by the compiler). Maybe at least add a news item to notify users?
(In reply to comment #6) > -Wl flags shouldn't be going through test-flags-PROG anyways. But they do go through it as soon as ebuild calls append-ldflags. (as of revision 1.157 of flag-o-matic.eclass)
You have a flag-o-matic.eclass I don't then because it just does `export LDFLAGS="${LDFLAGS} $*"` here. And since you wouldn't sanely put -Wl flags anywhere but LDFLAGS we're back to your original bug about -i flags, which I'm not sure we can support.
(In reply to comment #9) > You have a flag-o-matic.eclass I don't then because it just does `export > LDFLAGS="${LDFLAGS} $*"` here. Ouch, Ryan, I'm very sorry for my carelessness. I saw test-flag-PROG for {C,CXX,F,FC}FLAGS and I bet I saw it for LDFLAGS too. > And since you wouldn't sanely put -Wl flags anywhere but LDFLAGS we're back to > your original bug about -i flags, which I'm not sure we can support. Agree. Well, as soon as I don't have any new arguments for my point, I'm ok to close this bug.
