[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

GCC and binutils updates for buster

GCC 8 is available in testing/unstable, and upstream is approaching the first
point release.  I am planning to make GCC 8 the default at the end of the week
(gdc and gccgo already point to GCC 8).  Most runtime libraries built from GCC
are already used in the version built from GCC 8, so I don't expect runtime
incompatibilities anymore.  There is one more transistion involved, bumping the
libgfortran version.

A pre-release version of binutils 2.31 is in testing now, and the final 2.31
release in unstable.

These are the major versions for the upcoming buster release, still planning
updates to a potential GCC 8.3.0 (estimated Jan 2019) release and binutils
2.31.1 release, or doing equivalent updates from the release branches.

There are still a bunch of build failures triggered by GCC 8 [1], so fixing
these should get some priority now. See [2] for changes in GCC 8, and the
porting guide [3].  I'll be at DebCamp for the second half of the week, and at
DebConf, so if there is interest for bug squashing sessions, feel free to grab
me, and we can schedule such sessions on a short notice.

GCC 5 and GCC 6 are going away, and I am planning the same with GCC 7 as soon as
there are upstream kernel and glibc releases which are released after the GCC
8.1.0 release from April.

The Debian release team lists toolchain support for our release architectures,
and according to [4], the amd64, i386, armel, armhf, arm64 architectures are
supported as primary architectures, and s390x is supported as a secondary
architectures.  Some notes on other candidates for release architectures:

 - armel: The armv4t default isn't used very much anymore, and we had
   issues in the past.

 - armhf: While arm-linux-gnueabihf is not explicitly listed as a primary
   architecture, I'm told that the arm-linux-armeabi triplet covers the
   hard float variants as well.

 - ppc64el: Not documented as primary architecture, but according to the
   backend maintainers the powerpc64-linux-gnu triplet includes the le variant.

 - mips*: There is no support for any mips-linux target either as a primary
   or secondary release architecture (only bare metal), which matches the
   experience with mips specific issues for the past Debian releases.

I understand that port maintainers want to have their port included as a release
architecture, however it becomes a burden if neither the upstream nor the Debian
port maintainers can keep up with the general upstream development. Maybe we
need something in between the alternatives of being a release arch or not,
having the benefit of packages in testing/stable, but not being supported in a


[2] https://gcc.gnu.org/gcc-8/changes.html
[3] https://gcc.gnu.org/gcc-8/porting_to.html
[4] https://gcc.gnu.org/gcc-8/criteria.html

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: