Gentoo Archives: gentoo-dev

From: Mike Frysinger <vapier@g.o>
To: gentoo-dev@l.g.o
Subject: Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
Date: Fri, 07 Jul 2006 21:17:40
Message-Id: 200607071712.21536.vapier@gentoo.org
In Reply to: Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags) by "Harald van Dijk"
1 On Friday 07 July 2006 01:46, Harald van Dijk wrote:
2 > On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
3 > > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
4 > > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
5 > > > don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
6 > > > compiler in Gentoo.
7 > >
8 > > you're just griping because i forced ssp/pie regardless of USE=vanilla
9 > > ...
10 >
11 > I didn't mind that you applied ssp/pie patches regardless of
12 > USE=vanilla, I did mind that you applied the stub patches with
13 > USE="nossp vanilla", and I also didn't like that this was either done
14 > accidentally but ignored when pointed out, or that this was done
15 > deliberately with a misleading cvs log message.
16
17 it was not ignored, i told you the answer was no ... i listened to your
18 request and then i evaluated the situation and deemed at the time to go with
19 what we have now. see how your usage of "ignored" is incorrect here ?
20
21 as Kevin pointed out, the stubs do not affect code generation so i preferred
22 to keep users from breaking themselves
23
24 also, at the time, i told you you could easily work around the stub situation
25 by simply deleting them:
26 rm /usr/portage/sys-devel/gcc/files/stubs/*
27 and then add sys-devel/gcc/files/stubs/ to your rsync exclude list
28
29 once we have 4.1.1 in stable, i'll be happy to update the eclass to not apply
30 the stubs when USE=nossp as the majority of users will no longer be in the
31 situation i referred to earlier
32
33 > > since gcc-4.0 and below are on the way out, i have no problem changing
34 > > this behavior
35 > >
36 > > besides, since both of these technologies are in mainline gcc now, i
37 > > really dont see how you can continue to gripe with gcc-4.1.1+
38 >
39 > I don't know how much gcc-spec-env.patch can be trusted, and even if it
40 > is 100% safe, such patches don't belong in anything that would be called
41 > "vanilla". (I have commented on that patch long before this thread
42 > started, so don't think I'm just looking for something to complain about
43 > now.)
44
45 you never pointed that patch out to me nor did i notice it, so i dont really
46 see how you could have expected this to be fixed already
47
48 i'll update cvs when i get a chance
49 -mike

Replies