Created attachment 212150 [details] svn(1) diff against the ports tree The bug in PR 236616 resulted in virtualbox getting pinned to llvm7. This is less than ideal, and in-fact has been broken by improvements to machine/atomic.h on x86 that require a more modern compiler. Switch the build to use GCC9. USE_GCC= any is not sufficient, as GCC8 doesn't support the feature used by atomic.h. The patches that were previously applied if COMPILER_TYPE == clang are actually needed by GCC9 as well, so make those standard patches instead, folding the Config.kmk patches together. We should put some effort into testing llvm10 and working out why llvm breaks it, but fixing the build is more important at the moment. Q/A: * portlint (pre-existing issues; none in current patch) * testport (-CURRENT, amd64) * run tested by madpilot@
A commit references this bug: Author: kevans Date: Thu Mar 12 00:41:34 UTC 2020 New revision: 528258 URL: https://svnweb.freebsd.org/changeset/ports/528258 Log: emulators/virtualbox-ose: use contemporary GCC instead of old llvm The bug in PR 236616 resulted in virtualbox getting pinned to llvm7. This is less than ideal, and in-fact has been broken by improvements to machine/atomic.h on x86 that require a more modern compiler. Switch the build to USE_GCC= any. The patches that were previously applied if COMPILER_TYPE == clang are actually needed by newer GCCs as well, so make those standard patches instead, folding the Config.kmk patches together. We should put some effort into testing llvm10 and working out why llvm breaks it, but fixing the build is more important at the moment. Q/A: * portlint (pre-existing issues; none in current patch) * testport (-CURRENT, amd64) * run testing by madpilot@ PR: 244603 Approved by: koobs (mentor), bapt (mentor) Approved by: portmgr (blanket: build fix) MFH: 2020Q1 (blanket: build fix) Differential Revision: https://reviews.freebsd.org/D23967 Changes: head/emulators/virtualbox-ose/Makefile head/emulators/virtualbox-ose/files/extrapatch-Config.kmk head/emulators/virtualbox-ose/files/extrapatch-src-VBox-Devices-PC-ipxe-Makefile.kmk head/emulators/virtualbox-ose/files/extrapatch-src-recompiler-Makefile.kmk head/emulators/virtualbox-ose/files/patch-Config.kmk head/emulators/virtualbox-ose/files/patch-src-VBox-Devices-PC-ipxe-Makefile.kmk head/emulators/virtualbox-ose/files/patch-src-recompiler-Makefile.kmk
A commit references this bug: Author: kevans Date: Thu Mar 12 00:44:46 UTC 2020 New revision: 528259 URL: https://svnweb.freebsd.org/changeset/ports/528259 Log: MFH: r528258 emulators/virtualbox-ose: use contemporary GCC instead of old llvm The bug in PR 236616 resulted in virtualbox getting pinned to llvm7. This is less than ideal, and in-fact has been broken by improvements to machine/atomic.h on x86 that require a more modern compiler. Switch the build to USE_GCC= any. The patches that were previously applied if COMPILER_TYPE == clang are actually needed by newer GCCs as well, so make those standard patches instead, folding the Config.kmk patches together. We should put some effort into testing llvm10 and working out why llvm breaks it, but fixing the build is more important at the moment. Q/A: * portlint (pre-existing issues; none in current patch) * testport (-CURRENT, amd64) * run testing by madpilot@ PR: 244603 Approved by: koobs (mentor), bapt (mentor) Approved by: portmgr (blanket: build fix) Differential Revision: https://reviews.freebsd.org/D23967 Approved by: ports-secteam (blanket: build fix) Changes: _U branches/2020Q1/ branches/2020Q1/emulators/virtualbox-ose/Makefile branches/2020Q1/emulators/virtualbox-ose/files/extrapatch-Config.kmk branches/2020Q1/emulators/virtualbox-ose/files/extrapatch-src-VBox-Devices-PC-ipxe-Makefile.kmk branches/2020Q1/emulators/virtualbox-ose/files/extrapatch-src-recompiler-Makefile.kmk branches/2020Q1/emulators/virtualbox-ose/files/patch-Config.kmk branches/2020Q1/emulators/virtualbox-ose/files/patch-src-VBox-Devices-PC-ipxe-Makefile.kmk branches/2020Q1/emulators/virtualbox-ose/files/patch-src-recompiler-Makefile.kmk
VirtualBox GUI now segfaults on start (on FreeBSD 12.1, at least). I wonder if it is the cause.
(In reply to Gleb Popov from comment #3) Indeed, there's an open PR about it elsewhere. I'm frantically working on bissecting llvm to see if I can figure out where newer versions are broken.