Here's the latest iteration from openbsd-wip with jca's new devel/x86_64-elf/
toolchain instead of devel/binutils.

Packages and works fine for me.

Feedback? OK?

22.12.2025 03:13, Klemens Nanni пишет:
> 21.12.2025 20:42, Klemens Nanni пишет:
>> 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).
> 
> 
> fixed port after rereading upstream docs and code:
> - do not build arm64 .iso, fetched isolinux is amd64-only
> - pass CROSS and drop ARCH as per "Cross Compile" https://ipxe.org/appnote/buildtargets
>   - replace do-build with ALL_TARGET
>   - turn do-install into single pax command
> - tidy up makefile, less variables/ifs/loops
> 
> to illustrate, this yields ipxe-arm32-1.21.1pl1152.tgz:
> 
> |@@ -46,3 +46,3 @@ MAINTAINER =         Klemens Nanni <kn@openbsd.org>
> | # Cross-compilation architectures.
> |-FLAVORS =             aarch64
> |+FLAVORS =             aarch64 arm
> | FLAVOR ?=             # native build
> |@@ -61,4 +61,4 @@ BUILD_DEPENDS =      devel/arm-none-eabi/binutils,${FLAVOR} \
> |                       devel/arm-none-eabi/gcc,${FLAVOR}
> |-IPXE_ARCH =           ${FLAVOR:aarch64=arm64}
> |-CROSS =                       ${FLAVOR}-none-${FLAVOR:aarch64=elf}-
> |+IPXE_ARCH =           ${FLAVOR:aarch64=arm64:arm=arm32}
> |+CROSS =                       ${FLAVOR}-none-${FLAVOR:aarch64=elf:arm=eabi}-
> | .endif
> 
> it's in the port, but with arm commented in FLAVORS (until someone needs it).
> 
> images work for me and update-plist changes nothing.
> 
>>
>> Feedback? OK?

• ipxe.tgz (4K)