21.12.2025 15:42, Jeremie Courreges-Anglas пишет: > On Sat, Dec 13, 2025 at 05:07:39PM +0000, Klemens Nanni wrote: >> 22.11.2025 14:48, Klemens Nanni пишет: >>> The port itself supports any architecture, but builds only amd64 and arm64 >>> as others have not been tested (riscv64 and loongson might be of interest). >>> >>> It requires GNU tools incl. compiler and linker, we have everything except >>> - ports@ "binutils: enable ld.bfd ?" >>> >>> Once all knobs and found and set properly, GNU make compiles all files >>> always compiles all files (see https://dox.ipxe.org/ifdef_harmful.html) >>> and then links targets according to config. >>> >>> I want to be able to serve images for several architectures from a single >>> netboot server and avoid cross compilation, so this port uses MACHINE_ARCH >>> in PKGNAME and sets PKG_ARCH=*; per-arch files don't conflict and even >>> per-platform (e.g. EFI or BIOS) files seem to end up with unique tuples >>> of what upstream calls drivers and extensions, see Files below as well as >>> https://ipxe.org/appnote/buildtargets. >>> >>> Then I can serve, e.g. ipxe.efi over TFTP or HTTP and further do whatever >>> on the clients, for example through autoexec.ipxe, which it tries to load >>> from the server by default. >> Here's an updated and tidied version. As with binutils, I left support and >> merely omitted/commented arm64 in ONLY_FOR_ARCHS. >> >> The port is available in openbsd-wip. >> >> Feedback? OK to import once ports@ "binutils: enable ld.bfd ?" is settled? > > Not ok as is. Quoting my latest reply to the ld.bfd thread: > |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. > > The diff below is a *PoC* to build ipxe for aarch64 using > devel/arm-none-eabi/*,aarch64, allowing us to cross-compile from amd64 > and others if desired (tested, build succeeds then fails at pcbios, > but this is only a PoC). _I haven't tested the resulting aarch64 > standalone executables_. Right, i missed arm-none-eabi/gcc which has ld.bfd, thanks. BIOS on arm64 is not supported, so it cannot build.
amd64 from my new port tarball boots fine, arm64 gets tested later. > Obviously such a freestanding toolchain doesn't exist for i386/x86_64, > so we'd have to add that first if we wanted to go on the same path for > all architectures. Since I don't have a need for such a toolchain, > I'm not volunteering for the job. amd64 can build natively and cross every other architecture. I did that now through ONLY_FOR_ARCHS=amd64 FLAVORS=aarch64 FLAVOR= together with proper Makefile bits such that new architectures can be added for native- and/or cross-builds (after build and boot tests). Feedback? OK?
ipxe.tgz
Description: application/compressed-tar
