| 1 |
On Tue, Jun 17, 2014 at 6:01 PM, Barry Schwartz |
| 2 |
<chemoelectric@×××××××××××××.org> wrote: |
| 3 |
> Rich Freeman <rich0@g.o> skribis: |
| 4 |
>> Usually use flags that are discouraged are intended mainly to solve |
| 5 |
>> limitations in how we express dependencies/etc. It isn't that we |
| 6 |
>> don't want users to use them, but more that in the future we might |
| 7 |
>> change how they work and they could go away, causing trouble for those |
| 8 |
>> who depend on them. Think of them as unintentionally-exposed private |
| 9 |
>> interfaces. |
| 10 |
> |
| 11 |
> My view on this current problem is that, given -fno-stack-protector in |
| 12 |
> the make.conf works nearly everywhere, there isn’t a problem as far as |
| 13 |
> building the OS is concerned. As for a ‘user compiler’, this seems not |
| 14 |
> to be a serious change, either. |
| 15 |
> |
| 16 |
> (An example of actually making life harder for a user are the |
| 17 |
> default-settings changes in Debian’s GNU linker. They make it harder |
| 18 |
> than with stock GNU to construct dynamic plugins.) |
| 19 |
> |
| 20 |
|
| 21 |
As this topic is on-going, let my ask about -fno-stack-protector. I |
| 22 |
haven't messed with my build flags in literally years, and certainly |
| 23 |
not since I built this machine in 2010 where I only use CFLAGS="-O2 |
| 24 |
-march=native -pipe" . WRT to -fno-stack-protector does enabling a |
| 25 |
flag like that in make.conf then trigger a requirement to rebuild |
| 26 |
everything (emerge -e @world) or can one turn it on and just update |
| 27 |
the machine package-by-package over time? |
| 28 |
|
| 29 |
- Mark |
Archives