Created attachment 186268 [details] Log file With uefi-edk2-bhyve-20160704_2 the port won't build for me on 11.1 amd64. Please see attached log.
lang/gcc48 still installs include-fixed, so you need to make sure the package is in sync with the base system. For one, lang/gcc48 has to be rebuilt after upgrading from FreeBSD 11.0 to 11.1. /usr/local/bin/gcc48 -c -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -nostdlib -c -g -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/ BasePeCoff.c -o BasePeCoff.o In file included from /usr/include/sys/time.h:37:0, from /usr/include/sys/stat.h:99, from ../Common/CommonLib.h:173, from BasePeCoff.c:18: /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/include-fixed/sys/types.h:266:1: error: unknown type name '__vm_ooffset_t' typedef __vm_ooffset_t vm_ooffset_t; ^ /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/include-fixed/sys/types.h:268:1: error: unknown type name '__vm_pindex_t' typedef __vm_pindex_t vm_pindex_t; ^
Thanks. Recompiling lang/gcc48 did indeed resolve this issue. This should probably be added as a caveat in the port message.
A commit references this bug: Author: gerald Date: Sun Sep 17 21:03:03 UTC 2017 New revision: 450026 URL: https://svnweb.freebsd.org/changeset/ports/450026 Log: Backport a number of changes from lang/gcc5: - Move ONLY_FOR_ARCHS into the right position of the Makefile. - Omit a comment describing GCC_VERSION and SUFFIX. - Do not quote constant strings compared with ${ARCH}. [1] - Last, but not least the only functional change (and an important one): Remove headers being created by GCC's fixincludes machinery from the installation / packaging to avoid breakage when FreeBSD's headers are changing afterwards. [2] PR: 221905 [1], 222233 [2] Submitted by: linimon [1] Changes: head/lang/gcc49/Makefile
A commit references this bug: Author: gerald Date: Fri Sep 22 13:05:17 UTC 2017 New revision: 450370 URL: https://svnweb.freebsd.org/changeset/ports/450370 Log: Backport a number of changes from lang/gcc5 and lang/gcc49: - Move ONLY_FOR_ARCHS into the right position of the Makefile. - Omit a comment describing GCC_VERSION and SUFFIX. - Do not quote constant strings compared with ${ARCH}. [1] - Last, but not least the only functional change (and an important one): Remove headers being created by GCC's fixincludes machinery from the installation / packaging to avoid breakage when FreeBSD's headers are changing afterwards. [2] PR: 221905 [1], 222233 [2] Submitted by: linimon [1] Changes: head/lang/gcc48/Makefile
Okay, so I have now addressed the issue in lang/gcc48 (and also lang/gcc49) that has directly lead to this. However, a fundamental problem with this port is that if requires a version of GCC two versions (and hence two years) out of upstream support, soon three versions (and three years). Adjusting the description accordingly. Fabian, can you please look into this?
I've taken a look at it so far, and while it does seem to be possible to build the package with clang on Linux, it doesn't seem to work on FreeBSD so far. I've yet to properly understand the build system, but it doesn't seem to be a trivial change. Perhaps grehan@ (CC'ing him) might shed some light on this, as he added support for building on FreeBSD in the first place.
The port builds using gcc49, which is the most recent toolchain explicitly supported in that version of UEFI. However, using the trick of just replacing the gcc soft link when doing the setup (the line "ln -s /usr/local/bin/gcc48 Build/gcc" from the instructions at https://people.freebsd.org/~grehan/bhyve_uefi/bhyve-uefi-UDK2014.SP1-build.txt), I was able to get clean (untested) builds using ports gcc5 (gcc 5.4.0) and gcc6 (gcc 6.4.0) on a FreeBSD 12-current amd64 machine. It also built clean using ports gcc7 (7.2.0) after applying the one-line patch from the upstream UEFI git commit https://github.com/tianocore/edk2/commit/fe4a28ccbfd33 Perhaps the simplest way forward is to see what if any changes were made upstream to the UEFI build to support gcc5 (possibly none), back-port those to the bhyve UEFI branch, and cut over to gcc5 after verifying that the resultant UEFI binary is ok.
(In reply to Peter Grehan from comment #7) > The port builds using gcc49, which is the most recent toolchain explicitly > supported in that version of UEFI. If that is an option, moving from USE_GCC=4.8 to USE_GCC=4.9 would be one step forward. Not perfect, but definitely in the right direction. > Perhaps the simplest way forward is to see what if any changes were made > upstream to the UEFI build to support gcc5 (possibly none), back-port those to > the bhyve UEFI branch, and cut over to gcc5 after verifying that the resultant > UEFI binary is ok. That would be two steps even; definitely very nice progress!
I'm working with Scott Phillips on updating the port to build with gcc 8.
(In reply to Rebecca Cran from comment #9) > I'm working with Scott Phillips on updating the port to build with gcc 8. That sounds great, thank you! (This port is the last, or second to last, dependency we have on the quite aging lang/gcc48.)
This is still an issue, because only the -devel port got updated to the 20190424 release. We want to fix the CSM before updating the main port.
any news?