Cataclysm-dda: Stop supporting gcc 4.8

Created on 13 Oct 2018  路  15Comments  路  Source: CleverRaven/Cataclysm-DDA

Problem
While working on #26148 I had to add two different workarounds for bugs in gcc 4.8's standard library (specifically: that list::insert and list::splice don't accept const_iterator arguments). One of those required a const_cast.

Describe the solution you'd like
gcc 4.9 was released in 2014. Can we cease support for 4.8? Does the project have a policy on how far back it maintains compiler support?

Build Organization

Most helpful comment

As of this month:

  • Trusty is out of support and Xenial is the Ubuntu LTS, which defaults to gcc 5.3.
  • Debian stable is stretch, which defaults to gcc 6.3.
  • I'm not sure what you mean by Fedora whatsit, but the oldest supported Fedora version is 28, which appears to be using gcc 8 (though I'm less certain about Fedora packaging).
  • Mingw looks like it was using gcc 7.3 as of July 2018. Again, I'm not certain how mingw packaging works.
  • Code::Blocks is using gcc 5.1.

So, I'm reopening this and proposing we advance to a minimum gcc 5.1 (or maybe 5.3?). That gives us access to all of C++14 (and in the library). gcc 5.1's C++14 support might be buggy in some corner cases, so that's why I'd prefer 5.3.

All 15 comments

If we drop support for gcc-4.8, people won't be able to build C:DDA on default Red Hat Enterprise Linux 7 installations.

I don't think that's a good reason.

Ubuntu 14.04 LTS still uses gcc-4.8 and is supported through April 2019. I don't know if we need to match Ubuntu's LTS policy, but I also think we don't need to support gcc versions that aren't in a current Ubuntu LTS. So even if we decide not to remove gcc-4.8 support now, we should deprecate it and plan to remove it in April 2019.

I also think only supporting 3 or 4 years of gcc is a valid policy. I think 5 years is the maximum reasonable number, but a lower number is acceptable.

We aim to support as much compilers as possible to cover multiple rather old systems.

Some of the drivers of supporting old gccs;
Ubuntu LTS releases
Debian stable
Fedora whatsit releases
Mingw releases
Especially the mingw version bundled with Code::Blocks.

The goal here is minimizing the number of operations necessary for a new
contributor to achieve their first build. Patching in a new compiler can
be surprisingly difficult.

Cool. That makes sense. I'll close this issue for now.

As of this month:

  • Trusty is out of support and Xenial is the Ubuntu LTS, which defaults to gcc 5.3.
  • Debian stable is stretch, which defaults to gcc 6.3.
  • I'm not sure what you mean by Fedora whatsit, but the oldest supported Fedora version is 28, which appears to be using gcc 8 (though I'm less certain about Fedora packaging).
  • Mingw looks like it was using gcc 7.3 as of July 2018. Again, I'm not certain how mingw packaging works.
  • Code::Blocks is using gcc 5.1.

So, I'm reopening this and proposing we advance to a minimum gcc 5.1 (or maybe 5.3?). That gives us access to all of C++14 (and in the library). gcc 5.1's C++14 support might be buggy in some corner cases, so that's why I'd prefer 5.3.

Historically C::B has been the easiest way to get started on windows, so I'm hesitant to move past 5.1, but I'm not totally sure what people are using now, so if that's no longer the case we can step up to 5.3.

Related, #27690

C::B builds are partially broken now. I think MSYS is the easiest way now.

Well there you go, if it isn't even a reliable way of getting started, no need to accommodate it, we're good to bump to 5.3. At the same time, bump clang minimum version to one that supports c++14 at least, looks like 3.4. The main limiter for clang seems to be the version that Xcode is built on, so it might be reasonable to bump to something later than that, but I have no visibility into Xcode versions.

Cool. I'll work on one or more PRs for this.

When I update the docs about compiler support, is it appropriate to describe our position as:

We aim to support gcc and clang up to the newest stable versions and back to those shipping in any supported version of a popular distribution or relevant development environment, including Ubuntu, Debian, MSYS, and XCode.

We don't provide clang support in MSYS (yet), but it has version 8 by default and default gcc version there is either 7.4 or 8.3.

@narc0tiq I note that the Linux builds (Tiles and Curses) on the primary build matrix on Jenkins are using g++-4.8. How easy is that to change to something newer?

It's almost trivial to change it, I've got it on 4.8 only because it was the bottom of our support.

Please note that I've discovered there's no available package for gcc 5.3, so we're moving to 5.5 instead for the Linux 64 builds. At the same time, though, please double-check the Windows and OSX builds, as they tend to be non-trivial to upgrade.

Thanks! On Jenkins it looks like Windows builds are using gcc 5.4 and OS X build are using clang 3.8, so I think we're good there.

Was this page helpful?
0 / 5 - 0 ratings