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 version,...). 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.
Created attachment 197371 [details] Proposed patch
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.
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: http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/bowtie-1.1.2_6.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/canu-1.7_2.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/elmerfem-8.3.20170524_3.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/elfutils-0.172_1.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/libcwd-1.0.6_3.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/xtensa-esp32-elf-1.22.0.g20171219_2.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/dnsperf-2.1.0.0_1.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/bugle-0.0.20100508_12.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/cilkplus-rtl-20160603_4.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/gprolog-1.4.4_7.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/scm-5f2_7.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/scilab-5.5.2_14.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/dalton-2016.2.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/xcrysden-1.5.60_2.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/grub2-2.00_12.log http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/grub2-pcbsd-2.02q_13.log
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: http://package23.nyi.freebsd.org/data/112i386-default-PR231590/2018-10-29_06h48m09s/logs/errors/canu-1.7_2.log http://package23.nyi.freebsd.org/data/112i386-default-PR231590/2018-10-29_06h48m09s/logs/errors/elmerfem-8.3.20170524_3.log http://package23.nyi.freebsd.org/data/112i386-default-PR231590/2018-10-29_06h48m09s/logs/errors/libcwd-1.0.6_3.log http://package23.nyi.freebsd.org/data/112i386-default-PR231590/2018-10-29_06h48m09s/logs/errors/xtensa-esp32-elf-1.22.0.g20171219_2.log http://package23.nyi.freebsd.org/data/112i386-default-PR231590/2018-10-29_06h48m09s/logs/errors/dnsperf-2.1.0.0_1.log http://package23.nyi.freebsd.org/data/112i386-default-PR231590/2018-10-29_06h48m09s/logs/errors/bugle-0.0.20100508_12.log http://package23.nyi.freebsd.org/data/112i386-default-PR231590/2018-10-29_06h48m09s/logs/errors/cilkplus-rtl-20160603_4.log http://package23.nyi.freebsd.org/data/112i386-default-PR231590/2018-10-29_06h48m09s/logs/errors/gforth-0.7.3_9.log http://package23.nyi.freebsd.org/data/112i386-default-PR231590/2018-10-29_06h48m09s/logs/errors/gprolog-1.4.4_7.log http://package23.nyi.freebsd.org/data/112i386-default-PR231590/2018-10-29_06h48m09s/logs/errors/scilab-5.5.2_14.log http://package23.nyi.freebsd.org/data/112i386-default-PR231590/2018-10-29_06h48m09s/logs/errors/dalton-2016.2.log http://package23.nyi.freebsd.org/data/112i386-default-PR231590/2018-10-29_06h48m09s/logs/errors/xcrysden-1.5.60_2.log
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 Log: devel/libcwd: Unbreak build with GCC >= 8 conftest.cpp:11:36: error: return-statement with a value, in function returning 'void' http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/libcwd-1.0.6_3.log PR: 231590 Changes: head/devel/libcwd/files/patch-configure
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 Log: 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' http://package22.nyi.freebsd.org/data/112amd64-default-PR231590/2018-10-29_06h48m05s/logs/errors/bugle-0.0.20100508_12.log 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 Changes: head/graphics/bugle/Makefile
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?
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 Log: 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 Changes: head/lang/cilkplus/Makefile
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 Log: 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 Changes: head/lang/gprolog/Makefile
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 Log: Lock down to use GCC 7 since it does not build with GCC 8 nor clang. PR: 231590, 232961 Changes: head/sysutils/grub2/Makefile
PR232961 no longer blocks this update (but is still somewhat related).
Status update: I've filed PRs for and/or made to changes to more or less all affected ports.
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?
Gerald, can you land this before 2019Q1 branches?
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.
(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.
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 Log: 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 Changes: head/Mk/bsd.default-versions.mk
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. :-)