FWIW, I fixed the check introduced in binutils/Makefile rev 1.24.  See
http://build-failures.rhaalovely.net/aarch64/2025-12-17/devel/binutils.log

More input below,

On Sun, Nov 30, 2025 at 04:58:00PM +0100, Jeremie Courreges-Anglas wrote:
> On Sun, Nov 30, 2025 at 03:35:01PM +0000, Klemens Nanni wrote:
> > 30.11.2025 17:50, Jeremie Courreges-Anglas пишет:
> > > On Sun, Nov 30, 2025 at 02:30:06PM +0100, Frederic Cambus wrote:
> > >> On Sat, Nov 29, 2025 at 08:17:19PM +0000, Klemens Nanni wrote:
> > >>
> > >>>> net/ipxe in openbsd-wip seems to require the GNU linker.
> > >>>>
> > >>>> 2.17 from base just segfaults (certainly too old) and ld.lld(1) complains
> > >>>> differently, depending on what/how I build stuff:
> > >>>>
> > >>>> - ld: error: section .text file range overlaps with .shstrtab
> > >>>> - ld: error: output file too large: 18446744073709485768 bytes
> > >>>>
> > >>>> When using gld built with the diff below, ipxe.efi links fine.
> > > 
> > > I wonder whether ipxe should use a cross-compiling toolchain, allowing
> > > to build it from virtually any architecture, instead of the default
> > > toolchain on amd64 and arm64.  The only problem is that AFAIK we don't
> > > have such such a toolchain for x86.  So I guess it makes sense to use
> > > ld.bfd from default binutils instead.
> > 
> > I have next to no cross-compile experience on OpenBSD and only know about
> > our u-boot ports doing that.
> > 
> > Given that iPXE doesn't compile/link with LLVM, GNU ld is required whether
> > we build natively or for another architecture, no?
> 
> Yes.  u-boot is a good example of how to do it.
> 
> > Usage is limited and net/ipxe already is a non-trivial port,
> > so I just went with native builds, which do work just fine.

I still think that's the wrong way to go.  I see no point tying our
hands with building standalone programs using a generic "native
ports-gcc" + "native devel/binutils" toolchain, when all that is
needed is a freestanding toolchain.

Who will fix net/ipxe when it's on the way of a ports-gcc or devel/gas
update?  On this matter: you've explicitely made the devel/gas and
devel/binutils ports tightly bound, making it impossible to update
devel/gas without updating devel/binutils.  Someone updating devel/gas
would then feel forced to check that the new devel/binutils version
can still build net/ipxe on all architectures where it is enabled.

All of this disappears if you use cross-compiling with a stable
toolchain like u-boot does.

-- 
jca