Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

["Kevin F. Quinn" <kevquinn@gentoo.org>]

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

On Fri, 7 Jul 2006 07:46:16 +0200
Harald van Dijk <truedfx@gentoo.org> wrote:

> On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most
> > > patches don't get appplied, but some do. Plus, gcc[vanilla] isn't
> > > a supported compiler in Gentoo.
> > 
> > you're just griping because i forced ssp/pie regardless of
> > USE=vanilla ... 
> 
> I didn't mind that you applied ssp/pie patches regardless of
> USE=vanilla, I did mind that you applied the stub patches with
> USE="nossp vanilla", and I also didn't like that this was either done
> accidentally but ignored when pointed out, or that this was done
> deliberately with a misleading cvs log message.

If you take out the stub patches (which incidentally have no impact on
code generation), many builds will simply fail because they expect the
additional flags from ssp, htb etc to be there.

Since they have no impact on code generation, their presence doesn't
impact comparisons with a pure upstream release.

> > since gcc-4.0 and below are on the way out, i have no problem
> > changing this behavior
> > 
> > besides, since both of these technologies are in mainline gcc now,
> > i really dont see how you can continue to gripe with gcc-4.1.1+
> 
> I don't know how much gcc-spec-env.patch can be trusted, and even if
> it is 100% safe, such patches don't belong in anything that would be
> called "vanilla". (I have commented on that patch long before this
> thread started, so don't think I'm just looking for something to
> complain about now.)

Again, if you don't gave GCC_SPECS defined in your environment then
that patch makes no difference to code generation.

-- 
Kevin F. Quinn

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