[Bug 292544] Failed to build edk2-bhyve g202508.
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 292544] Failed to build edk2-bhyve g202508."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 19 Jan 2026 10:16:52 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292544 --- Comment #8 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to DYM from comment #7) The build on the official builder machine for the official-port-package worked just fine. Its log shows use of git-ar with @ in use and it did not fail: "gcc-ar" cr /wrkdirs/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint/OUTPUT/UefiDriverEntryPoint.lib @/wrkdirs/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint/OUTPUT/object_files.lst When the build process is finding the right files for gcc-ar and ar, the build works. The @ use is not the problem, nor is use of —plugin : they worked fine in the official build. The @ use handled the .lst file correctly. Use under portmaster is using the wrong ar that does not even support @ or —plugin notation. The port needs to control which ar is found in the overall live system. It is a classic example of why portmaster and Makefile use without having a isolated/clean environment makes it more difficult to get various port builds to work. -- You are receiving this mail because: You are the assignee for the bug.