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.
> 
> > 
> >>>>
> >>>> 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).
> 
> Right, didn't think about the conflict.  The idea behind a flavor was
> to not build ld by default and hav net/ipxe's build (only on two archs)
> build it.
> 
> I also agree on subpackages with you here.
> 
> > Please don't enable this only on amd64 and arm64.  We need fewer
> > differences between architectures, and certainly not more of them.
> 
> If so, we probably want more build-tests before committing it,
> otherwise it might fail on some archs and take down whatever depends
> on binutils.

Nothing depends on binutils at the moment.  Indeed this port will need
some tweaks on some architectures (backports from base probably).
Sigh.  Maybe restricting this to amd64 and arm64 is more reasonable
indeed...

I wonder if it would be less effort to provide a stripped down
binutils port for bare x86_64, like arm-none-eabi/binutils.  Care to
show your ipxe port and how it is currently using gld from binutils?

> Could someone please give this a try on anything other than:
> arm64 amd64 i386 octeon?

Builds and packages on sparc64

The list of "safe" architectures where we could enable gld without
patches can probably be determined, but gotta head out now.

-- 
jca