All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [for-next 3/3] package/gcc: remove gcc 4.9
Date: Wed, 14 Jun 2017 00:04:52 +0200	[thread overview]
Message-ID: <874lvjbl2z.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <6c88ceb4-94f7-6018-6d3a-ae3e99c8d44e@mind.be> (Arnout Vandecappelle's message of "Sun, 11 Jun 2017 22:30:30 +0200")

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >> I'll wait a little bit for additional feedback on this one. If nobody
 >> complains in the next few days, I'm going to apply it.

 >  GCC 4.9 (or rather, GCC 5) is a bit a special case: libstdc++ had heavy
 > ABI-incompatible changes. E.g. at the time Debian switched to it, it was the
 > only time I had major breakage in sid. So, the switch from gcc 4.9 to gcc 5
 > means that any binary-only C++ program will no longer be usable.

 That probably is a bigger issue for a binary distribution like Debian
 than for Buildroot though.


 >  On top of that, gcc 5 introduces many errors (for non-standard-compliant code)
 > that were accepted before in gcc 4.9, which makes existing codebases sometimes
 > difficult to get built. This, however, happens with each version bump so less of
 > an argument against removal.

True. It also breaks older u-boot and Linux kernel versions that didn't
handle > gcc4.x.


 >  You could say that users with such requirements should keep using their own
 > toolchain, but there are useful (security) fixes in libc as well. They could use
 > an external toolchain, but then how to build it? Crosstool-NG is a *lot* more
 > complicated to use than Buildroot.

But we also don't keep old libc versions around. Would they be Ok with
moving to a new libc version but not to newer gcc version?


 >  Bottom line: I'd tend to keep gcc 4.9 around for a while. If
 > breakage occurs we can disallow it for some architectures. There
 > shouldn't be much more maintenance effort than that, I think.

I can follow you, and it is OK for me to keep 4.9 around for a little
while longer. We always have this tradeoff between stability and adding
new features / cleanups, and I do think people should be moving to the
LTS version (and plan in time for a yearly migration to the new LTS) if
they want stability and fixes for a longer period, just like they
(hopefully) do for their Linux kernel.

We should imho drop 4.9 before the next LTS though.

-- 
Bye, Peter Korsgaard

  reply	other threads:[~2017-06-13 22:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-25 18:34 [Buildroot] [for-next 1/3] package/gcc: remove old hashes (gcc 4.5, 4.7, 4.8) Romain Naour
2017-05-25 18:34 ` [Buildroot] [for-next 2/3] package/gcc: switch to gcc 6.x as the default Romain Naour
2017-05-26 13:13   ` Thomas Petazzoni
2017-05-25 18:34 ` [Buildroot] [for-next 3/3] package/gcc: remove gcc 4.9 Romain Naour
2017-05-26 13:14   ` Thomas Petazzoni
2017-06-11 20:30     ` Arnout Vandecappelle
2017-06-13 22:04       ` Peter Korsgaard [this message]
2017-06-14  5:30         ` Arnout Vandecappelle
2017-06-14  6:56           ` Thomas Petazzoni
2017-06-14  7:06             ` Peter Korsgaard
2017-07-01  8:40               ` Romain Naour
2017-06-14  7:03           ` Peter Korsgaard
2017-07-08  6:16   ` daggs
2017-07-09  9:44     ` Romain Naour
2017-05-26 13:13 ` [Buildroot] [for-next 1/3] package/gcc: remove old hashes (gcc 4.5, 4.7, 4.8) Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874lvjbl2z.fsf@dell.be.48ers.dk \
    --to=peter@korsgaard.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.