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.

> > > 
> > > Is there a reason disable it?
> > 
> > If yes, would a FLAVOR (that is not hooked up) and/or enabling it
> > only for amd64 and arm64 (none other needed, atm) be acceptable?
> 
> There was simply no use-case for it, because as far as I remember it is
> not going to produce working OpenBSD executables.
> 
> Adding a FLAVOR would probably be overkill, but as it will only be useful
> to build net/ipxe on amd64 and arm64 I think it indeed makes sense to only
> enable building ld on these architectures.

If that FLAVOR has to be used to build ports then it is by definition
hooked up, and possibly conflicting at build time with the default
FLAVOR.  I see only downsides with using a FLAVOR here.  A SUBPACKAGE
could perhaps make sense, but I doubt it's worth the additional
complexity.  The renaming to *g*ld(.bfd) should prevent any port from
accidentaly using it instead of base ld(1) or ld.bfd(1).

Please don't enable this only on amd64 and arm64.  We need fewer
differences between architectures, and certainly not more of them.

-- 
jca