[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On Tue, 10 Jun 2014 04:31:27 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Mon, 9 Jun 2014 18:16:02 -0600
> Ryan Hill <rhill@gentoo.org> wrote:
> 
> > Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be
> > enabled by default.[..]
> 
> .. on supported architectures.
> 
> 
> Right?

Yes.  But now you've got me worried.  We have to build gcc itself with
-fno-stack-protector.  Does compiling something with that flag give an error on
hppa?  Maybe give 4.8.2-r1 a whirl.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Jeroen Roovers]

On Mon, 9 Jun 2014 21:46:56 -0600
Ryan Hill <rhill@gentoo.org> wrote:

> Yes.  But now you've got me worried.  We have to build gcc itself with
> -fno-stack-protector.  Does compiling something with that flag give
> an error on hppa?  Maybe give 4.8.2-r1 a whirl.

Setting -fstack-protector on HPPA does this:

warning: -fstack-protector not supported for this target [enabled by
 default]

Setting -fno-stack-protector on HPPA causes no problems and is
completely silent.


     jer

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Anthony G. Basile]

On 06/10/14 08:22, Jeroen Roovers wrote:
> On Mon, 9 Jun 2014 21:46:56 -0600
> Ryan Hill <rhill@gentoo.org> wrote:
>
>> Yes.  But now you've got me worried.  We have to build gcc itself with
>> -fno-stack-protector.  Does compiling something with that flag give
>> an error on hppa?  Maybe give 4.8.2-r1 a whirl.
> Setting -fstack-protector on HPPA does this:
>
> warning: -fstack-protector not supported for this target [enabled by
>   default]
>
> Setting -fno-stack-protector on HPPA causes no problems and is
> completely silent.
>
>
>       jer
>

The error means exactly that, that no gcc dev has bother to write the 
code to generate stack canaries.  It does suck since that warning is 
going to be everywhere.  This was the case with mips + ssp until gcc-4.7 
(if I recall correctly).

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Anthony G. Basile]

On 06/10/14 10:35, Magnus Granberg wrote:
> tisdag 10 juni 2014 14.22.11 skrev  Jeroen Roovers:
>> On Mon, 9 Jun 2014 21:46:56 -0600
>>
>> Ryan Hill <rhill@gentoo.org> wrote:
>>> Yes.  But now you've got me worried.  We have to build gcc itself with
>>> -fno-stack-protector.  Does compiling something with that flag give
>>> an error on hppa?  Maybe give 4.8.2-r1 a whirl.
>> Setting -fstack-protector on HPPA does this:
>>
>> warning: -fstack-protector not supported for this target [enabled by
>>   default]
>>
>> Setting -fno-stack-protector on HPPA causes no problems and is
>> completely silent.
>>
>>
>>       jer
> The arch that ssp will be enable by default is defined in the ebuild with
> SSP_STABLE or SSP_UCLIBC_STABLE.
>
> /Magnus
>
>

Will that remove the flag from hppa?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Magnus Granberg]

tisdag 10 juni 2014 14.22.11 skrev  Jeroen Roovers:
> On Mon, 9 Jun 2014 21:46:56 -0600
> 
> Ryan Hill <rhill@gentoo.org> wrote:
> > Yes.  But now you've got me worried.  We have to build gcc itself with
> > -fno-stack-protector.  Does compiling something with that flag give
> > an error on hppa?  Maybe give 4.8.2-r1 a whirl.
> 
> Setting -fstack-protector on HPPA does this:
> 
> warning: -fstack-protector not supported for this target [enabled by
>  default]
> 
> Setting -fno-stack-protector on HPPA causes no problems and is
> completely silent.
> 
> 
>      jer
The arch that ssp will be enable by default is defined in the ebuild with
SSP_STABLE or SSP_UCLIBC_STABLE.

/Magnus

[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

On Tue, 10 Jun 2014 09:48:53 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> On 06/10/14 10:35, Magnus Granberg wrote:
> > tisdag 10 juni 2014 14.22.11 skrev  Jeroen Roovers:
> >> On Mon, 9 Jun 2014 21:46:56 -0600
> >>
> >> Ryan Hill <rhill@gentoo.org> wrote:
> >>> Yes.  But now you've got me worried.  We have to build gcc itself with
> >>> -fno-stack-protector.  Does compiling something with that flag give
> >>> an error on hppa?  Maybe give 4.8.2-r1 a whirl.
> >> Setting -fstack-protector on HPPA does this:
> >>
> >> warning: -fstack-protector not supported for this target [enabled by
> >>   default]
> >>
> >> Setting -fno-stack-protector on HPPA causes no problems and is
> >> completely silent.
> >>
> >>
> >>       jer
> > The arch that ssp will be enable by default is defined in the ebuild with
> > SSP_STABLE or SSP_UCLIBC_STABLE.
> >
> > /Magnus
> >
> >
> 
> Will that remove the flag from hppa?

Yes, the spec rule is applied only if the arch defines SSP_STABLE.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On Tue, 10 Jun 2014 14:22:11 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Mon, 9 Jun 2014 21:46:56 -0600
> Ryan Hill <rhill@gentoo.org> wrote:
> 
> > Yes.  But now you've got me worried.  We have to build gcc itself with
> > -fno-stack-protector.  Does compiling something with that flag give
> > an error on hppa?  Maybe give 4.8.2-r1 a whirl.
> 
> Setting -fstack-protector on HPPA does this:
> 
> warning: -fstack-protector not supported for this target [enabled by
>  default]
> 
> Setting -fno-stack-protector on HPPA causes no problems and is
> completely silent.

Okay, we're good to go then.  Thanks for testing.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

v2: Restrict by arch
--

Title: GCC 4.8.3 defaults to -fstack-protector
Author: Ryan Hill <rhill@gentoo.org>
Content-Type: text/plain
Posted: 2014-06-10
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: >=sys-devel/gcc-4.8.3
Display-If-Keyword: amd64
Display-If-Keyword: arm
Display-If-Keyword: mips
Display-If-Keyword: ppc
Display-If-Keyword: ppc64
Display-If-Keyword: x86

Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be
enabled by default.  The 4.8 series will enable -fstack-protector
while 4.9 and later enable -fstack-protector-strong.

SSP is a security feature that attempts to mitigate stack-based buffer
overflows by placing a canary value on the stack after the function
return pointer and checking for that value before the function returns.
If a buffer overflow occurs and the canary value is overwritten, the
program aborts.

There is a small performance cost to these features.  They can be
disabled with -fno-stack-protector.

For more information these options, refer to the GCC Manual, or the
following articles.

http://en.wikipedia.org/wiki/Buffer_overflow_protection
http://en.wikipedia.org/wiki/Stack_buffer_overflow
https://securityblog.redhat.com/tag/stack-protector
http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Jeroen Roovers]

On Tue, 10 Jun 2014 21:47:50 -0600
Ryan Hill <rhill@gentoo.org> wrote:

> v2: Restrict by arch
> --
> 
> Title: GCC 4.8.3 defaults to -fstack-protector
> Author: Ryan Hill <rhill@gentoo.org>
> Content-Type: text/plain
> Posted: 2014-06-10
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: >=sys-devel/gcc-4.8.3
> Display-If-Keyword: amd64
> Display-If-Keyword: arm
> Display-If-Keyword: mips
> Display-If-Keyword: ppc
> Display-If-Keyword: ppc64
> Display-If-Keyword: x86
> 
> Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be
> enabled by default.  The 4.8 series will enable -fstack-protector
> while 4.9 and later enable -fstack-protector-strong.

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.


     jer

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Greg Turner]

On Wed, Jun 11, 2014 at 6:23 AM, Jeroen Roovers <jer@gentoo.org> 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!

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Magnus Granberg]

torsdag 12 juni 2014 03.45.23 skrev  Greg Turner:
> On Wed, Jun 11, 2014 at 6:23 AM, Jeroen Roovers <jer@gentoo.org> 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!

Glibc don't compile well with -fstack-protector* and that way we pass
-fno-stack-protector to the compiler when we build the lib. It is done in 
common.eblit where we check if the compiler have the ssp spec added as 
hardened and the default gcc 4.9 and 4.8.3 have.

The problem was when user did add -fstack-protector* to the cflag for the check 
didd't check that and upstream will just invalid the bug if you try to compile 
it with -fstack-protector*.
/Magnus

[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

On Wed, 11 Jun 2014 15:23:15 +0200
Jeroen Roovers <jer@gentoo.org> 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.

Bugzilla seems to be down so I can't look up the bug, but I doubt it's a
problem since you can't build glibc with -fstack-protector.

glibc/files/eblits/common.eblit:
  gcc-specs-ssp && append-cflags $(test-flags-CC -fno-stack-protector)

Previously this was also dependent on `use hardened` so whatever that bug is
about it probably doesn't apply any more.

I've been running the ssp patches here for the last six months and have rebuilt
world a few dozen times with both 4.8 and 4.9 and haven't run into any
problems.  That doesn't mean there aren't any, but that's why we added 4.8.2-r1
half a year ago so people could test it.  Did anyone actually try it out?  I
honestly want to know - if no one is testing masked versions then there's no
point keeping them masked for as long as I usually do.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Jeroen Roovers]

On Thu, 12 Jun 2014 23:43:55 -0600
Ryan Hill <rhill@gentoo.org> wrote:

> On Wed, 11 Jun 2014 15:23:15 +0200
> Jeroen Roovers <jer@gentoo.org> 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.
> 
> Bugzilla seems to be down so I can't look up the bug, but I doubt
> it's a problem since you can't build glibc with -fstack-protector.

The problem I see is that anyone who wants to switch to having
-fstack-protector enabled by default early will run into the glibc
problem (much as I did), when all the bug reports that point out the
problem have been closed as INVALID. A simple `strip-flags
-fstack-protector' in the appropriate (non-hardened?) cases should
prevent more duplicate bug reports, I guess.


     jer

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Rich Freeman]

On Fri, Jun 13, 2014 at 9:22 AM, Jeroen Roovers <jer@gentoo.org> wrote:
> The problem I see is that anyone who wants to switch to having
> -fstack-protector enabled by default early will run into the glibc
> problem (much as I did), when all the bug reports that point out the
> problem have been closed as INVALID. A simple `strip-flags
> -fstack-protector' in the appropriate (non-hardened?) cases should
> prevent more duplicate bug reports, I guess.

++

If we know everybody is going to be on -fstack-protector in a few
months just add the strip-flags statement to the ebuild and be done
with it.  Squabbling over whether those using the flag are bringing
breakage upon themselves is like trying to hold back the sea.  We
should be encouraging people to add the flag and report bugs, and if a
package doesn't work with it and doesn't strip it I think we should
consider it a package bug now.

Ten years ago when it was fairly unsupported the argument made more
sense (you can't filter every little thing that can break a package).

Rich

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Greg Turner]

On Fri, Jun 13, 2014 at 6:38 AM, Rich Freeman <rich0@gentoo.org> wrote:
> add the strip-flags statement to the ebuild and be done
> with it

To do it "greenly" we'd obviously want to know the precise surface
area of the problem and then to correctly express those circumstances
in eblit code that could stand up to the test of time.  Anyone know
what exactly /is/ the surface area of the problem?  Already the eblit
filters the flag iff ( gcc-specs-ssp && test-flags-CC
-fno-stack-protector )

-gmt

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Joshua Kinard]

On 06/13/2014 14:08, Greg Turner wrote:
> On Fri, Jun 13, 2014 at 6:38 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> add the strip-flags statement to the ebuild and be done
>> with it
> 
> To do it "greenly" we'd obviously want to know the precise surface
> area of the problem and then to correctly express those circumstances
> in eblit code that could stand up to the test of time.  Anyone know
> what exactly /is/ the surface area of the problem?  Already the eblit
> filters the flag iff ( gcc-specs-ssp && test-flags-CC
> -fno-stack-protector )

Does anyone know of an upstream glibc bug on this?  The version referenced
in #332823 is 2.12, which is a bit old.  Does this still happen on 2.19?  I
have to assume that the glibc folks will eventually have to take a look at
this if gcc is going to make SSP default in 4.8.3 and up.  If there is a
patch available for glibc to correct this, that might be the better path.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Joshua Kinard]

On 06/13/2014 14:08, Greg Turner wrote:
> On Fri, Jun 13, 2014 at 6:38 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> add the strip-flags statement to the ebuild and be done
>> with it
> 
> To do it "greenly" we'd obviously want to know the precise surface
> area of the problem and then to correctly express those circumstances
> in eblit code that could stand up to the test of time.  Anyone know
> what exactly /is/ the surface area of the problem?  Already the eblit
> filters the flag iff ( gcc-specs-ssp && test-flags-CC
> -fno-stack-protector )

I just found this on our forums, too.  Kinda odd that a change of -march
args to gcc would apparently correct the same problem.  I don't have a
non-hardened system available that can test this, though.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Joshua Kinard]

On 06/13/2014 14:41, Joshua Kinard wrote:
> On 06/13/2014 14:08, Greg Turner wrote:
>> On Fri, Jun 13, 2014 at 6:38 AM, Rich Freeman <rich0@gentoo.org> wrote:
>>> add the strip-flags statement to the ebuild and be done
>>> with it
>>
>> To do it "greenly" we'd obviously want to know the precise surface
>> area of the problem and then to correctly express those circumstances
>> in eblit code that could stand up to the test of time.  Anyone know
>> what exactly /is/ the surface area of the problem?  Already the eblit
>> filters the flag iff ( gcc-specs-ssp && test-flags-CC
>> -fno-stack-protector )
> 
> I just found this on our forums, too.  Kinda odd that a change of -march
> args to gcc would apparently correct the same problem.  I don't have a
> non-hardened system available that can test this, though.
> 

::headdesk:: Forgot to include the link:
http://forums.gentoo.org/viewtopic-t-861624-view-next.html

Some googling suggests that the __libc_multiple_libcs multiple definition
error is triggered by a variety of things.  Kinda like when glibc fails
midway through the sunrpc folder.  There's a GCC-4.7 regression that fixed
one in gcc bug #51117.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

On Fri, 13 Jun 2014 09:38:32 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Fri, Jun 13, 2014 at 9:22 AM, Jeroen Roovers <jer@gentoo.org> wrote:
> > The problem I see is that anyone who wants to switch to having
> > -fstack-protector enabled by default early will run into the glibc
> > problem (much as I did), when all the bug reports that point out the
> > problem have been closed as INVALID. A simple `strip-flags
> > -fstack-protector' in the appropriate (non-hardened?) cases should
> > prevent more duplicate bug reports, I guess.

Ah, okay.  I agree.  Thanks for pointing this out.

> If we know everybody is going to be on -fstack-protector in a few
> months just add the strip-flags statement to the ebuild and be done
> with it.  Squabbling over whether those using the flag are bringing
> breakage upon themselves is like trying to hold back the sea.  We
> should be encouraging people to add the flag and report bugs, and if a
> package doesn't work with it and doesn't strip it I think we should
> consider it a package bug now.

I think if a package breaks with any of the -f/-g flags that strip-flags
considers safe it's a legitimate package bug.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 475 bytes --]