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
