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

[Martin Schlemmer]

On Sat, 2006-07-08 at 13:51 +0200, Harald van Dijk wrote:
> On Sat, Jul 08, 2006 at 11:27:57AM +0200, Martin Schlemmer wrote:
> > On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote:
> > > On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote:
> > > > On Friday 07 July 2006 19:04, Harald van Dijk wrote:

> > > > like i said in my previous e-mail, forcing stubs onto people even when
> > > > USE=vanilla *is by design* because i got tired of people who had no clue
> > > > about the consequences throwing USE=vanilla into their USE in make.conf and
> > > > then complaining when the lack of SSP broke things ...
> > >
> > > But I'm not asking for USE="vanilla" to disable SSP completely, I'm only
> > > asking for USE="vanilla nossp" to disable it. "nossp" is already
> > > explicitly documented as "NOT FOR GENERAL USE", too.
> > >
> >
> > No offence, but you are being very unreasonable in this thread.  The
> > fact that you can get what you are after, even though its not entirely
> > supported, should be enough for you, especially for the fact that you
> > are not clueless.
> >
> > You should remember that somebody at the end of the day have to
> > sacrifice time and effort to fix bugs, and especially with something as
> > complex as gcc, the more variables, the more effort it is going to be.
> > And as Mike is relatively the only person currently who seems to
> > maintain gcc, it should be his prerogative to decided that he get too
> > much spam without the stubs.
>
> Sorry, but how much mail he gets does not affect one bit which behaviour
> is better, it only helps understand why the lesser behaviour could be
> chosen by reasonable people anyway. (Regardless of which behaviour is
> the lesser one.) And I don't harass anyone about -- it's been a very
> long time since I even mentioned any problems like this, and if nothing
> is done after this thread dies, I'll likely be quiet about it for a long
> time again -- so please don't act like I do.
>

Actually it does if it cuts back his time by a very large percentage so
that he cannot do the other things he wants/needs to.  I assume this was
the case if he added that in the first place, and still refuse to change
it.

> > > 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.
> >
> > For the fact that we do not support vanilla gcc - I assume this is a gcc
> > built by yourself -
>
> Actually, I meant gcc built with the vanilla flag here, as opposed to
> pure official GCC, which I already stated is unsupported earlier.
>

Hmm, thought I might have had it a tad wrong.  I still though do not
understand what the whole fuss is about stubs for some 5 flags.  (which
is what you are left with with USE="vanilla nossp" currently if my
memory is correct).  Maybe read down a bit before replying here.

> >                     this truly is really unfair of you to expect it.
> > The 'contract' we usually have with upstream, is that if we apply
> > patches to their software, we will be the first tier in the support
> > chain.  Now you want to run gcc which was not modified by us to fix the
> > known hangups in how we do things - or save us time for that matter, and
> > you still want us to support it - or at least make life easier for us by
> > not leaving gaping holes that cost us maintenance time?
>
> Differences between official GCC and Gentoo's GCC are 1) fixed bugs, and
> 2) added features. (Assuming no patches are broken.) I think it's
> reasonable to not rely on the existence of those added features.

I think its reasonable to no force the feature on you, but add the stubs
if it became a maintenance headache.  I am pretty sure it was not
toolchain who brought the whole situation about in the first place.

You can however fix the tree to make sure it will fully build without
those flags, and then talk to Mike again about removing them.  I am sure
he might be more willing if it will not steal his time again.

>  You
> seem to think I think it's reasonable to not rely on bugs being
> fixed. No problem there, I don't.
>

Not at all.  I thought you think its reasonable to just keep loading
work on other people - or possible did not see that that would have been
the end result.  More about this to the end.

> Besides, I said it's unfortunate that vanilla GCC (either one) is
> unsupported, not that it must be. My other problem, that vanilla
> GCC is different from Gentoo's GCC with the vanilla flag (plus maybe
> nossp/nopie/...), can be handled without requiring support for it from
> anyone.
>

From the length of this email, and you not wanting to see the reasoning,
or not having started to fix the tree so that your wish can be full
filled, It rather sounded like you did demand it.  Or this was at least
the impression I got.

Also once again I do not see what the big issue with the stubs is.  You
keep making a big issue out of it without giving concrete examples or
serious issues it is causing.  The problem was there before they were
added, and not due to them - its even possible that with test_flag() its
less of an issue now.  Still read down a bit before replying here.

> > The alternative to this that you seem to ignore, is that you can start
> > helping maintaining gcc (I am sure Mike will appreciate help with
> > Halcy0n gone as well, and me not having that much time currently).
>
> Since I'm more interested in vanilla GCC, I think there's little to help
> maintain from Gentoo's side (support in ebuilds, and possibly the build
> process, that's it). If that's something you think help would be good
> for anyway, though, sure, if I can.
>

Vanilla, Gentoo patched - they all have bugs which bugzilla have more
than enough of in.  And in the perfect world Gentoo patched gcc will
have less bugs than the Vanilla one.

> >                                                                    And
> > of course promising so long as the stubs do not get applied with nossp,
> > that you will handle all breakage in that area.
>
> I have no problems modifying ebuilds / packages to autodetect flags
> instead of assuming they exist myself, if it means vanilla GCC will be
> supported feature-wise, for those versions of which the corresponding
> Gentoo-patched version is supported.
>

OK, maybe I was just too dense to see it before, or maybe you kept
dancing around the issue.  To put it clear (or try at least), your whole
issue currently is that you cannot use a 'Vanilla' gcc (ie without the
stubs) to build everything in the tree ?  And not as much the stubs them
selfs ?

If this is the case, then I think you have been barking up the wrong
tree this whole time.  It was not toolchain who assumed flags are
present in some gcc to whatever packages - we just maintain the
toolchain.  And I am sure not all the blame will fall on hardened
either, as many package maintainers for packages that would not work
with SSP might have fixed it by just disabling it via CFLAGS.

So really, hitting the specific maintainers or upstream with a clue
stick would have been the logical solution that did not bog down
toolchain even more.

> >                                                 Although I do not know
> > if its still really fair to expect Jakub et ell to sacrifice time to
> > process the bugs, and get them to you if its related to something
> > failing due to the missing stubs.
>
> I /could/ read toolchain@ mail if I would help out with GCC, you know,
> which is where such bugs should end up going to currently (those not
> closed as dupes) if the package maintainer thinks it's a bug that some
> GCC version doesn't support a particular flag. :) Or am I
> misunderstanding?

I think you understood wrongly.

If the stubs were to be just removed say tomorrow, and breakage in the
tree is still of such an extend that bugs starts to flood in again, its
not just you that will have to read the mail.  If the user is clueless,
then Jakub have to reassign the bug to either toolchain or the package
maintainer.  If he could not determine it was due to the missing CFLAG,
and it ended up with the package maintainer, then they would have had to
reassign it to toolchain.  Either case, if it was a very bad report,
they would first have to spend time and effort in getting the correct
information.  And besides all that, for each reassignment or comment to
the bug, it would have been extra mail that a few or possible a lot of
people had to have spend time on to read (except if they >/dev/null it,
but then they could miss possible need to check them selfs on it again).

So I really just wanted to make you think about how things could (and
probably did) cascade before the stubs was added.



-- 
Martin Schlemmer