Created attachment 172457 [details] v1 Respect GCC version preference in make.conf e.g., DEFAULT_VERSIONS=gcc=5 . I've only checked poudriere build with the following configuratins. - 10.3R amd64, gcc48, uefi-edk2-bhyve + uefi-edk2-bhyve-csm: OK - 10.3R amd64, gcc5, uefi-edk2-bhyve + uefi-edk2-bhyve-csm: OK
related to bug #211079, USE_GCC adds a RUN_DEPEND
Reporter is committer, assign accordingly
Resign - still no approval. Not sure why the patch here is blocked by bug 211079 but Clang remains out of scope i.e., after -Werror stuff it fails as $ BaseTools/Source/C/bin/GenFw -o Build/BhyveX64/RELEASE_GCC48/X64/BhyvePkg/BhyveAcpiTables/BhyveAcpiTables/OUTPUT/./Facp.acpi -c Build/BhyveX64/RELEASE_GCC48/X64/BhyvePkg/BhyveAcpiTables/BhyveAcpiTables/OUTPUT/./Facp.dll GenFw: ERROR 3000: Invalid Build/BhyveX64/RELEASE_GCC48/X64/BhyvePkg/BhyveAcpiTables/BhyveAcpiTables/OUTPUT/./Facp.dll unsupported ELF EM_X86_64 relocation 0x18. GenFw: ERROR 3000: Invalid Build/BhyveX64/RELEASE_GCC48/X64/BhyvePkg/BhyveAcpiTables/BhyveAcpiTables/OUTPUT/./Facp.dll unsupported ELF EM_X86_64 relocation 0x18.
Is this still relevant?
It's more relevant than ever, now that gcc48 is deprecated.
It looks like upstream has fixed at least some of the problems with Clang. https://github.com/tianocore/edk2/commit/d3bb711834acd3eda35a07d0be7911bc3dbb9e6f
The "ERROR 3000" message is due to the build trying to use the system ld linker. Installing binutils from ports and setting up symlinks such that /usr/local/bin/ld is used lets the build complete.
Alan: one problem is that bhyve is stuck on the pretty ancient UDK2014 or UDK2014.SP1 branch (I can't recall which). Once I get my current work on UEFI support in the loader and installer out the way I plan to work on updating BhyvePkg to work with UDK2018.
Created attachment 215412 [details] patch This fix build with gcc9. Try to fix clang but it require more time to dig into build system.
Thanks. I'm actually in the process of updating the port to use the latest edk2-stable202005 code: the last hurdle is fixing CSM support. When that's done, there should be no more problems with using newer versions of GCC, though CLANG will still need work.
Take this ticket, since I'm working on updating the port.
(In reply to Rebecca Cran from comment #11) > Take this ticket, since I'm working on updating the port. Thank you, Rebecca!
I check, port with my patch build - ok. Lets merge it and close this ticket.
Created attachment 222443 [details] patch
(In reply to rozhuk.im from comment #14) I'm not an expert in this port nor area, but even I can see some nice improvements such as the loop to create syslinks. Just to make sure, are all the AS="${AS}" etc. in MAKE_ARGS really required? And changing USE_GCC=4.8:build to USE_GCC=yes means that GCC becomes a run time dependency, when it previous was not. I believe you'll want USE_GCC=yes:build . (This port is listing ports@FreeBSD.org as maintainer, so removing the ask on Fabian.)
I still have a patch at https://reviews.freebsd.org/D27230 I'm hoping to commit some time (once the PCIe passthrough regression is resolved).
Created attachment 222462 [details] patch
I've just committed an update to the port that allows it to build using any modern version of gcc. See https://svnweb.freebsd.org/ports?view=revision&revision=565866 for details.
Build ok on 13.