On Wed, Jun 11, 2014 at 6:23 AM, Jeroen Roovers <[email protected]> wrote: > > Will bug #332823 and its ilk somehow be mitigated? Emerging glibc with > -fstack-protector still leads to similar problems. There doesn't > currently seem to be a bug report about this that isn't marked INVALID.
Is this a bug/limitation in glibc's actual code, or in glibc's build environment? Asked another (wordier) way -- should I understand -- assuming nobody adds some explicit -fno-stack-protector to the non-hardened profiles or the glibc ebuild -- and, of course, also that the user has not put it in make.conf or similar -- that this would break glibc compilation in the base configurations of the x86/amd64 non-hardened profiles?* If that's so... that doesn't sound so great, does it? Just thinking out loud, I guess, but, the fact -- if it is, indeed, still a fact (?) -- that, as of gcc-4.8.2, putting -fstack-protector in your CFLAGS breaks glibc.ebuild doesn't /necessarily/ mean that, as of gcc-4.8.3, leaving -fno-stack-protector out of your cflags would also break it, even if they are supposed to mean the same thing -- that would depend on the specific etiology of the problem. Sorry, perhaps Google Search would answer my question as readily as portage, in which case, by all means feel free to "lmgtfy" my ass. But if nobody knows the answer for sure, presumably you have the means to find out, Ryan? If for any reason you need a guinea-pig, I have a non-hardened triple-multilib (but mostly ABI_X86="64 32") workstation, here, that I'm not afraid to break. -gmt *Apologies for the horrific run-on sentence!
