21.12.2025 15:26, Jeremie Courreges-Anglas пишет: > > 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
Thanks! > > 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. Fixing it would be up to me as maintainer, if that doesn't go anywhere we could always mark such leaf ports as BROKEN so as not to block progress. > All of this disappears if you use cross-compiling with a stable > toolchain like u-boot does. Wouldn't it require ld.bfd still which devel/arm-none-eabi/gcc/ lacks? Regardless of cross-compilation, amd64 does and will require native tools from devel/binutils, so I don't see a way around building ld.bfd there. Either way, net/ipxe is amd64-only as of now. Starting with this and having failed with the native binutils approach, I'd be happy to try adapting u-boot's approach. Do you want this before import or can we work on it in-tree? Thanks for your input and help, much appreciated.
