Bug 231590

Summary: [exp-run] Update GCC_DEFAULT from 7 to 8
Product: Ports & Packages Reporter: Gerald Pfeifer <gerald>
Component: Ports FrameworkAssignee: Gerald Pfeifer <gerald>
Status: Closed FIXED    
Severity: Affects Many People CC: jbeich, linimon, portmgr, ports-bugs
Priority: --- Flags: gerald: exp-run?
Version: Latest   
Hardware: Any   
OS: Any   
Bug Depends on: 232929, 232930, 232933, 232958, 232959, 232960    
Bug Blocks: 238330, 238429    
Description Flags
Proposed patch none

Description Gerald Pfeifer freebsd_committer 2018-09-22 15:40:34 UTC
After late updates to GCC 4.8 and GCC 4.9 (both of which were unmaintained
upstream at that point), with GCC 5 we were ahead of the curve a little,
and the updates to GCC 6 and GCC 7 came when these had at least a year
of upstream lifetime left.

Let's see whether we can now move to the latest upstream release series,
GCC 8, which would be unprecedented since the update to GC 4.2 (in base
back then)!

This *should* be easier now, with many ports fixed during those upgrades
above (be it in terms of code, be it in terms of honoring CFLAGS and the
like, be it in terms of yanking them from the tree, updating to a newer

Sooo, let's see how many ports need to be fixed (once again), and how
long that takes this time...

https://gcc.gnu.org/gcc-8/porting_to.html and
https://gcc.gnu.org/gcc-8/changes.html may be useful resources for
anyone helping.
Comment 1 Gerald Pfeifer freebsd_committer 2018-09-22 19:17:39 UTC
Created attachment 197371 [details]
Proposed patch
Comment 2 Jan Beich freebsd_committer 2018-10-25 01:53:06 UTC
Ping. Can you do exp-run at least on 11.2? 10.4 (too late) and 12.0 (too early) can be ignored for now.
Comment 3 Antoine Brodin freebsd_committer 2018-10-30 15:52:39 UTC
New failures on amd64:

+ {"origin"=>"biology/bowtie", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"biology/canu", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"cad/elmerfem", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"devel/elfutils", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"devel/libcwd", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"devel/xtensa-esp32-elf", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"dns/dnsperf", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"graphics/bugle", "phase"=>"build", "errortype"=>"new_compiler_error"}
+ {"origin"=>"lang/cilkplus", "phase"=>"build", "errortype"=>"new_compiler_error"}
+ {"origin"=>"lang/gprolog", "phase"=>"build/runaway", "errortype"=>"runaway_process"}
+ {"origin"=>"lang/scm", "phase"=>"build", "errortype"=>"process_failed"}
+ {"origin"=>"math/scilab", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"science/dalton", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"science/xcrysden", "phase"=>"build", "errortype"=>"compiler_error"}
+ {"origin"=>"sysutils/grub2", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"sysutils/grub2-pcbsd", "phase"=>"build", "errortype"=>"nested_declaration"}

New failure logs on amd64:

Comment 4 Antoine Brodin freebsd_committer 2018-10-30 15:54:54 UTC
New failures on i386:

 {"origin"=>"biology/canu", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"cad/elmerfem", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"devel/libcwd", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"devel/xtensa-esp32-elf", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"dns/dnsperf", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"graphics/bugle", "phase"=>"build", "errortype"=>"new_compiler_error"}
+ {"origin"=>"lang/cilkplus", "phase"=>"build", "errortype"=>"new_compiler_error"}
+ {"origin"=>"lang/gforth", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"lang/gprolog", "phase"=>"build/runaway", "errortype"=>"runaway_process"}
+ {"origin"=>"math/scilab", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"science/dalton", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"science/xcrysden", "phase"=>"build", "errortype"=>"compiler_error"}

New failure logs on i386:

Comment 5 commit-hook freebsd_committer 2018-10-30 18:05:04 UTC
A commit references this bug:

Author: tobik
Date: Tue Oct 30 18:04:17 UTC 2018
New revision: 483505
URL: https://svnweb.freebsd.org/changeset/ports/483505

  devel/libcwd: Unbreak build with GCC >= 8

  conftest.cpp:11:36: error: return-statement with a value, in function returning 'void'


  PR:		231590

Comment 6 commit-hook freebsd_committer 2018-10-30 18:22:18 UTC
A commit references this bug:

Author: tobik
Date: Tue Oct 30 18:21:30 UTC 2018
New revision: 483506
URL: https://svnweb.freebsd.org/changeset/ports/483506

  graphics/bugle: Lock it to GCC 7 and deprecate

  It fails to build with GCC >= 8:

  cc1: error: unrecognized command line option '-fdump-translation-unit'


  The Changelog at [1] for newer versions says it's no longer developed,
  so deprecate it as well:

  "This is a bugfix release. BuGLe is no longer actively developed."

  [1] https://sourceforge.net/projects/bugle/files/bugle/0.0.20150628/

  PR:		231590

Comment 7 Gerald Pfeifer freebsd_committer 2018-11-03 14:12:12 UTC
Antoine, dnsperf looks like a false positive: this appears to be using
the system compiler aka clang 6.0.0.

Possibly one of the many, many regressions introduced by the clang update?
Comment 8 commit-hook freebsd_committer 2018-11-03 14:22:08 UTC
A commit references this bug:

Author: gerald
Date: Sat Nov  3 14:22:04 UTC 2018
New revision: 483896
URL: https://svnweb.freebsd.org/changeset/ports/483896

  GCC 8 removed CilkPlus support, so we cannot USE_GCC=yes.  Instead
  force the use of GCC 7, the last version with CilPlus support.

  PR:		231590

Comment 9 commit-hook freebsd_committer 2018-11-03 14:42:27 UTC
A commit references this bug:

Author: gerald
Date: Sat Nov  3 14:42:22 UTC 2018
New revision: 483898
URL: https://svnweb.freebsd.org/changeset/ports/483898

  The last years this port, based on an upstream abandoned half a decade
  ago, has merely seen patching and prodding by several of us, often when
  it got into the way of updates of other parts of the Ports Collection.

  This is the case once again with a pending update of GCC to version 8,
  where we run into

    gmake[2]: Entering directory '/wrkdirs/usr/ports/lang/gprolog/work/gprolog-1.4.4/src/Fd2C'
    gplc -c --fast-math fd2c.pl
    =>> Killing runaway build after 7200 seconds with no output

  after already workarounds in place for other versions of remotely
  recent compilers.  Bite the bullet and mark for deprecation and
  removal one-and-a-half months from now

  PR:		231590

Comment 10 commit-hook freebsd_committer 2018-11-04 14:01:04 UTC
A commit references this bug:

Author: gerald
Date: Sun Nov  4 14:00:52 UTC 2018
New revision: 484054
URL: https://svnweb.freebsd.org/changeset/ports/484054

  Lock down to use GCC 7 since it does not build with GCC 8 nor clang.

  PR:		231590, 232961

Comment 11 Gerald Pfeifer freebsd_committer 2018-11-04 20:49:42 UTC
PR232961 no longer blocks this update (but is still somewhat related).
Comment 12 Gerald Pfeifer freebsd_committer 2018-11-04 21:43:38 UTC
Status update: I've filed PRs for and/or made to changes to more or less
all affected ports.
Comment 13 Gerald Pfeifer freebsd_committer 2018-11-18 23:12:40 UTC
PR 232936 has been addressed, and now builds with both clang and GCC 8,
so removing the blocking dependency.

With that, I think, we're essentially ready to do this update of GCC_DEFAULT.
I mainly need to find a stretch of time to properly work on the PORTREVSION
bumping - probably next weekend?
Comment 14 Jan Beich freebsd_committer 2018-12-05 02:03:59 UTC
Gerald, can you land this before 2019Q1 branches?
Comment 15 Jan Beich freebsd_committer 2018-12-05 02:08:14 UTC
Preferably, with at least 1 week to spare. Since the last exp-run 1 month ago there're probably new USE_GCC consumers or some old ones switched to it.
Comment 16 Gerald Pfeifer freebsd_committer 2018-12-11 21:25:26 UTC
(In reply to Jan Beich from comment #14)
> Gerald, can you land this before 2019Q1 branches?

Definitely so!  I wanted to make sure I've got time for this in one
piece and actually started to script identifying the ports requiring
a PORTREVISION bump to make this automated and more resilient going
forward, so it's taking a bit longer, but will be a lot easier now.
Comment 17 commit-hook freebsd_committer 2018-12-11 21:29:10 UTC
A commit references this bug:

Author: gerald
Date: Tue Dec 11 21:28:32 UTC 2018
New revision: 487260
URL: https://svnweb.freebsd.org/changeset/ports/487260

  Update the default version of GCC pulled in via USE_GCC=yes and a myriad
  other ways from GCC 7 (7.4 right now) to GCC 8 (8.2 right now).

  This is the first time for eons, if not forever, that we are on the most
  recent major version of GCC, a catch-up that's been taking more than two
  years with the great help of many fellow committers and volunteers.

  PR:		231590
  Tested by:	antoine (exp-runs)
  Thanks to:	jbeich, tobik, jwb, mi, yuri, and others for helping fix (broken) ports

Comment 18 Gerald Pfeifer freebsd_committer 2018-12-12 03:11:54 UTC
Okay, so bumping PORTREVISIONS was more involved than I had planned for:

First my Internet connection broke down just while I was on it, but also
a surprisingly number of ports now does all sorts of "interesting" things
around PORTREVISIONS, such as including other Makefiles etc.

In any case, even if the SVN->Bugzilla bridge did not appear to work in
this case (perhaps because the summary with all affected files was quite
large?) this landed earlier today, so closing this issue.  Yeah. :-)