I have a similar problem. And when I try to run the build again:

...
<skip>
Active Platform          = /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/OvmfPkg/Bhyve/BhyveX64.dsc
.... done!
Building ... /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/NetworkPkg/Library/DxeNetLib/DxeNetLib.inf [X64]
Building ... /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib.inf [X64]
make[1]: Entering directory '/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib'
rm -f /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/DxeNetLib.lib
"gcc-ar" cr /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/DxeNetLib.lib  @/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/object_files.lst
ar: invalid option -- @
usage:  ar -d [-Tjsvz] archive file ...
	ar -m [-Tjsvz] archive file ...
	ar -m [-Tabijsvz] position archive file ...
	ar -p [-Tv] archive [file ...]
	ar -q [-TcDjsUvz] archive file ...
	ar -r [-TcDjsUuvz] archive file ...
	ar -r [-TabcDijsUuvz] position archive file ...
	ar -s [-jz] archive
	ar -t [-Tv] archive [file ...]
	ar -x [-CTouv] archive [file ...]
	ar -V
make[1]: *** [GNUmakefile:301: /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/DxeNetLib.lib] Error 1
make[1]: Leaving directory '/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib'
Building ... /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf [X64]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint]


build.py...
 : error F002: Failed to build module
	/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/NetworkPkg/Library/DxeNetLib/DxeNetLib.inf [X64, GCC, RELEASE]

- Failed -
Build end time: 08:15:19, Jan.18 2026
Build total time: 00:00:05

*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/edk2

It seems that the problem lies in passing the path to the object_files.lst file.

===
"gcc-ar" cr /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/DxeNetLib.lib  @/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/object_files.lst
===

Part by part:

"gcc-ar"

cr

/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/DxeNetLib.lib

@/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/object_files.lst

In the last part, there should be no “@” symbol at the beginning.

Created attachment 267261 [details]
The difference between the generated file and the correct file

The problem is in the file:
/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/GNUmakefile

Line 301:

"$(SLINK)" cr /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/DxeNetLib.lib $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)

Part by part:

"$(SLINK)"

cr

/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/DxeNetLib.lib

$(SLINK_FLAGS)

@$(OBJECT_FILES_LIST)
^

The "@" symbol is unnecessary in the last part.

Similarly for:

edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/GNUmakefile


edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/GNUmakefile

However, even if this is corrected, the following error occurs:
==================================================
Active Platform          = /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/OvmfPkg/Bhyve/BhyveX64.dsc
.... done!
Building ... /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/NetworkPkg/Library/DxeNetLib/DxeNetLib.inf [X64]
Building ... /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib.inf [X64]
Building ... /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf [X64]
make[1]: Entering directory '/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib'
rm -f /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/DxeNetLib.lib
"gcc-ar" cr /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/DxeNetLib.lib  /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/object_files.lst
ar: unrecognized option `--plugin'
usage:  ar -d [-Tjsvz] archive file ...
	ar -m [-Tjsvz] archive file ...
	ar -m [-Tabijsvz] position archive file ...
	ar -p [-Tv] archive [file ...]
	ar -q [-TcDjsUvz] archive file ...
	ar -r [-TcDjsUuvz] archive file ...
	ar -r [-TabcDijsUuvz] position archive file ...
	ar -s [-jz] archive
	ar -t [-Tv] archive [file ...]
	ar -x [-CTouv] archive [file ...]
	ar -V
make[1]: *** [GNUmakefile:301: /usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib/OUTPUT/DxeNetLib.lib] Error 1
make[1]: Leaving directory '/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib'


build.py...
 : error 7000: Failed to execute command
	make tbuild [/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeNetLib/DxeNetLib]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/Build/BhyveX64/RELEASE_GCC/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib]


build.py...
 : error F002: Failed to build module
	/usr/ports/sysutils/edk2/work-bhyve/edk2-edk2-stable202508/NetworkPkg/Library/DxeNetLib/DxeNetLib.inf [X64, GCC, RELEASE]

- Failed -
Build end time: 09:49:24, Jan.18 2026
Build total time: 00:00:06

*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/edk2
==================================================

Resume:
that, this is not a “single symbol problem”.

Created attachment 267262 [details]
patch v2

Some notes about the context:

gcc-ar is a gcc wrapping script intended for use with
binutils ar as it is in contexts like Linux: gcc-ar
has the purpose of implicitly/.automatically adding a
--plugin SO_NAME to the ar command line formed to
select the bintuils ar related plugin for giving ar
LTO support.

It appears that, for exmaple, lang/gcc15 installs a:

# file /usr/local/bin/gcc-ar15
/usr/local/bin/gcc-ar15: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 15.0 (1500065), FreeBSD-style, stripped


It is also the case that the use of the "@" notation
is part of the bintuils ar context (like on Linux):

QUOTE from https://man7.org/linux/man-pages/man1/ar.1.html :
      @file
           Read command-line options from file.  The options read are
           inserted in place of the original @file option.  If file does
           not exist, or cannot be read, then the option will be treated
           literally, and not removed.

           Options in file are separated by whitespace.  A whitespace
           character may be included in an option by surrounding the
           entire option in either single or double quotes.  Any
           character (including a backslash) may be included by prefixing
           the character to be included with a backslash.  The file may
           itself contain additional @file options; any such options will
           be processed recursively.
END QUOTE

It appears that devel/binutils installs the likes of:

# file /usr/local/bin/ar
/usr/local/bin/ar: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 15.0 (1500065), FreeBSD-style, stripped


Given that mostly-upstream sort of background information
. . .

I'll note that llvm-ar has:

QUOTE from "man 1 ar" on FreeBSD:
     @<FILE>
            Read command-line options and commands from response file <FILE>.
END QUOTE

Removing a "@" from in front of a response file's
name or path on a command line does not appear to
be sufficient to produce correct/intended behavior
in any context, though it may well change the error
reports that result.

As for the "ar: unrecognized option `--plugin'": that
would tend to suggest it is not a message from a
normal binutils ar implementation. For example:

# /usr/local/bin/ar --plugin
/usr/local/bin/ar: option `--plugin' requires an argument
. . .

The "man 7 ar" output for freebsd reports:

QUOTE
     Here's where llvm-ar departs from previous ar implementations:

     The following option is not supported
        [f] - truncate inserted filenames

     The following options are ignored for compatibility
        --plugin=<string> - load a plugin which adds support for other file
        formats

        [l] - ignored in ar
END QUOTE

But that means using llvm-ar would not produce the
error message:

# which ar
/usr/bin/ar

# ar -V
LLVM (http://llvm.org/):
  LLVM version 19.1.7
  Optimized build.

# ar --plugin
ar: error: plugin requires an argument

I've no clue what the port's intent is for the
commands in question as shown in the patch. But it
does not look like the patch is appropriate on its
own.

Given the way portmaster works, I've no clue which
or where it might be finding the gcc-ar or ar that
end up being used. But it does not seem to be any
of the above for the "ar" command, given the ar
command's message about --plugin notation on the
command line.

Sorry. This is NOT a patch that needs to be applied. It is for illustrative purposes only, was an attempt to understand what the problem was. I know that the rabbit hole goes deeper.
I just tried to find a starting point from which to move forward. It is clear that the build proceeded quite successfully after removing the ‘@’ symbol. But it stopped at a similar problem, not with a symbol, but with a set of symbols.
And, yes, this build is not for Linux, it is an edk2 build for bhyve, AFAIK it is only on BSD.
Unfortunately, I don't have time to dig deeper right now. I hope that someone (perhaps from the maintainers) will be able to move forward and the problem will be solved.

(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.

What does portmaster have to do with it? I don't use it.
I use the ports tree and the make command directly, after first enfore changing to the port directory.

# cd /usr/ports/sysutils/edk2 && make

(In reply to DYM from comment #9)

portmaster internally also uses "the ports tree and the make command directly"
without any issolated/clean environment for the build. portmaster use and use
like "cd /usr/ports/sysutils/edk2 && make" tend to have the same sort of
problems on this area. If one has a problem finding the right command to
execute, I'd expect the other to as well.

I had intended my wording to cover both of those contexts, even if I was not
clear.

It also turns out that the recent commit removed notation for controlling
which "ar" is found and used (the ar=${AR} notation below was deleted):

 # Heavily dependent on bsd.port.pre.mk definitions for lang/gcc* details:
 BINARY_ALIAS=	make=${GMAKE} \
-		dtc=${LOCALBASE}/bin/dtc \
-		ar=${AR} \
 		gcc=${LOCALBASE}/bin/${CC} \
-		gcc-ar=${LOCALBASE}/bin/${CC:S/gcc/&-ar/} \
 		g++=${LOCALBASE}/bin/${CXX} \
+		gcc-nm=${LOCALBASE}/bin/${CC:S/gcc/&-nm/} \
+		gcc-ar=${LOCALBASE}/bin/${CC:S/gcc/&-ar/} \
+		gcc-ranlib=${LOCALBASE}/bin/${CC:S/gcc/&-ranlib/} \
 		python3=${PYTHON_CMD} python=${PYTHON_CMD}

I do not know why ar=${AR} was removed.

Alexey <9vlc@proton.me> is the author and Robert Clausecker <fuz@FreeBSD.org>
is the committer if you want to ask them.

Reinstating the ar assignment ("ar=${AR}") fixes the problem for me.

(In reply to Piotr Smyrak from comment #11)
Restoring (add) string in Makefile on BINARY_ALIAS:
ar=${AR}
Yes, it working fine.

(In reply to DYM from comment #12)

It might be good to delete the 2 attachments as they might confuse things
for folks reading them at this point.

(In reply to Mark Millard from comment #10)

Oh no, I must have removed that on accident. I'll submit a patch for 202511 with the variable back.

(In reply to Alexey from comment #14)

I've no clue if:

-		dtc=${LOCALBASE}/bin/dtc \

has a similar issue for its deletion or not.

(In reply to Alexey from comment #14)

Also unclear, why:

-USE_GCC=	yes:build
+USE_GCC=	yes

causing a runtime dependency when what is built (EDK2) runs
as firmware (even for the bhyve EDK2) instead of as a FreeBSD
program/library.

USE_GCC=	yes:build

looks right to me.

I'm having the build problem shown in comment #1.  Should I use one (or both) of the patches given to fix the problem?

(In reply to George Mitchell from comment #17)

No patch or commit for any of the comments #11 / #12, #14, #15, or #16 has
done as far as I know. (Those are all related to the BINARY_ALIAS text
part of comment #10 .)

The existing 2 Attachments are misleading and do not address the underlying
problem(s). They should be ignored.