On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao <r...@gentoo.org> wrote: > 1. The kernel expects -fno-stack-protector to be the default. What will > the effect be on kernel configuration once -fstack-protector is the default?
Nothing, since the kernel build system doesn't source make.conf. If somebody creates an ebuild that actually installs a kernel then it might be an issue, though it could be filtered if it is a problem. > > 2. We should make sure that -fno-stack-protector is a supported CFLAG. > This will make it easier to handle complaints from the vocal minority of > our user base that want every last percentage point of performance. No reason that it would be any less supported than -fstack-protector already is. > > 3. I would like to point out that we are talking about deviating from > upstream behavior and everyone is okay with it. Anyone who thinks we > should stick to upstream when it is not good for us should speak now or > risk being asked "where were you when..." whenever they try to use > upstream as an excuse to hold back progress. ;) I don't really see this as an issue - in general maintainers are expected to accommodate reasonable CFLAGS. This doesn't mean that arbitrary CFLAGS are "supported" so much as bugs should be taken seriously if they're really bugs. If -fstack-protector causes serious problems and this is inherent to the nature of the package/etc then just filter it. If it causes problems because upstream isn't doing things right, then this is no different than how things were 10 years ago when we were stomping out amd64 issues left and right (not working on amd64 wasn't a reason to mask a package for x86, but we didn't accept "upstream doesn't care about amd64" as an excuse). Staying close to upstream is a good philosophy in general. I don't think that means that we can't have reasonable CFLAGS. Otherwise we wouldn't set CFLAGS at all and would just use whatever defaults the upstream build system applies. We're a distro - doing integration work is a value-add, not a sin. If we aren't doing integration, then users might as well just do Linux-from-scratch. Rich
