| 1 |
On 09/10/2013 09:17 PM, Rich Freeman wrote: |
| 2 |
> On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao <ryao@g.o> wrote: |
| 3 |
>> 1. The kernel expects -fno-stack-protector to be the default. What will |
| 4 |
>> the effect be on kernel configuration once -fstack-protector is the default? |
| 5 |
> |
| 6 |
> Nothing, since the kernel build system doesn't source make.conf. If |
| 7 |
> somebody creates an ebuild that actually installs a kernel then it |
| 8 |
> might be an issue, though it could be filtered if it is a problem. |
| 9 |
|
| 10 |
My understanding is that this change would be made to GCC's spec files, |
| 11 |
which affects everything that uses GCC. |
| 12 |
|
| 13 |
>> |
| 14 |
>> 2. We should make sure that -fno-stack-protector is a supported CFLAG. |
| 15 |
>> This will make it easier to handle complaints from the vocal minority of |
| 16 |
>> our user base that want every last percentage point of performance. |
| 17 |
> |
| 18 |
> No reason that it would be any less supported than -fstack-protector |
| 19 |
> already is. |
| 20 |
|
| 21 |
Just making certain. |
| 22 |
|
| 23 |
>> |
| 24 |
>> 3. I would like to point out that we are talking about deviating from |
| 25 |
>> upstream behavior and everyone is okay with it. Anyone who thinks we |
| 26 |
>> should stick to upstream when it is not good for us should speak now or |
| 27 |
>> risk being asked "where were you when..." whenever they try to use |
| 28 |
>> upstream as an excuse to hold back progress. ;) |
| 29 |
> |
| 30 |
> I don't really see this as an issue - in general maintainers are |
| 31 |
> expected to accommodate reasonable CFLAGS. This doesn't mean that |
| 32 |
> arbitrary CFLAGS are "supported" so much as bugs should be taken |
| 33 |
> seriously if they're really bugs. If -fstack-protector causes serious |
| 34 |
> problems and this is inherent to the nature of the package/etc then |
| 35 |
> just filter it. If it causes problems because upstream isn't doing |
| 36 |
> things right, then this is no different than how things were 10 years |
| 37 |
> ago when we were stomping out amd64 issues left and right (not working |
| 38 |
> on amd64 wasn't a reason to mask a package for x86, but we didn't |
| 39 |
> accept "upstream doesn't care about amd64" as an excuse). |
| 40 |
> |
| 41 |
> Staying close to upstream is a good philosophy in general. I don't |
| 42 |
> think that means that we can't have reasonable CFLAGS. Otherwise we |
| 43 |
> wouldn't set CFLAGS at all and would just use whatever defaults the |
| 44 |
> upstream build system applies. We're a distro - doing integration |
| 45 |
> work is a value-add, not a sin. If we aren't doing integration, then |
| 46 |
> users might as well just do Linux-from-scratch. |
| 47 |
> |
| 48 |
> Rich |
| 49 |
> |
| 50 |
|
| 51 |
Past events have led me to think that we are sometimes too dependent on |
| 52 |
upstream for guidance. I have certainly deviated from upstream whenever |
| 53 |
it made sense and the results have been fairly positive. I am not saying |
| 54 |
that acting for the best interests of Gentoo is mutually exclusive with |
| 55 |
collaboration with upstream, but I am saying that the two sometimes |
| 56 |
conflict. This being one of them. I am taking this opportunity to point |
| 57 |
out that what is best for Gentoo should come first and that it is okay |
| 58 |
to make decisions on our own. |
Archives