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?

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.

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


Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/binutils/Makefile,v
diff -u -p -r1.23 Makefile
--- Makefile	29 Nov 2025 18:11:04 -0000	1.23
+++ Makefile	30 Nov 2025 15:31:47 -0000
@@ -3,7 +3,7 @@ COMMENT =	GNU binary utilities
 # keep version synchronized with devel/gas
 V =		2.45.1
 DISTNAME =	binutils-${V}
-REVISION =	0
+REVISION =	1
 
 CATEGORIES =	devel
 
@@ -28,7 +28,6 @@ CONFIGURE_STYLE =	gnu
 
 CONFIGURE_ARGS +=	--disable-gas \
 			--disable-gprof \
-			--disable-ld \
 			--disable-libctf \
 			--disable-nls \
 			--disable-install-libbfd \
Index: patches/patch-ld_configure_tgt
===================================================================
RCS file: patches/patch-ld_configure_tgt
diff -N patches/patch-ld_configure_tgt
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ patches/patch-ld_configure_tgt	30 Nov 2025 14:01:55 -0000
@@ -0,0 +1,15 @@
+recognise arm64
+
+Index: ld/configure.tgt
+--- ld/configure.tgt.orig
++++ ld/configure.tgt
+@@ -98,6 +98,9 @@ aarch64-*-freebsd*)	targ_emul=aarch64fbsd
+ aarch64-*-fuchsia*)	targ_emul=aarch64elf
+ 			targ_extra_emuls="aarch64elfb armelf armelfb"
+ 			;;
++aarch64-*-openbsd*)	targ_emul=aarch64obsd
++			targ_extra_emuls="aarch64obsdb aarch64elf"
++			;;
+ aarch64_be-*-linux-gnu_ilp32)
+ 			targ_emul=aarch64linux32b
+ 			targ_extra_libpath="aarch64linuxb aarch64linux aarch64linux32 armelfb_linux_eabi armelf_linux_eabi"
Index: pkg/DESCR
===================================================================
RCS file: /cvs/ports/devel/binutils/pkg/DESCR,v
diff -u -p -r1.1.1.1 DESCR
--- pkg/DESCR	7 Aug 2022 20:44:09 -0000	1.1.1.1
+++ pkg/DESCR	30 Nov 2025 15:33:50 -0000
@@ -4,6 +4,7 @@ This package contains the following GNU 
 - ar - A utility for creating, modifying and extracting from archives.
 - c++filt - Filter to demangle encoded C++ symbols.
 - elfedit - Update ELF header and program property of ELF files.
+- ld - Links files.
 - nm - Lists symbols from object files.
 - objcopy - Copies and translates object files.
 - objdump - Displays information from object files.
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/binutils/pkg/PLIST,v
diff -u -p -r1.4 PLIST
--- pkg/PLIST	24 Sep 2025 17:03:55 -0000	1.4
+++ pkg/PLIST	30 Nov 2025 15:32:05 -0000
@@ -3,6 +3,8 @@
 @bin bin/gar
 @bin bin/gc++filt
 @bin bin/gelfedit
+@bin bin/gld
+@bin bin/gld.bfd
 @bin bin/gnm
 @bin bin/gobjcopy
 @bin bin/gobjdump
@@ -12,12 +14,17 @@
 @bin bin/gstrings
 @bin bin/gstrip
 @info info/binutils.info
+@info info/ld.info
+@info info/ldint.info
 @info info/sframe-spec.info
+lib/bfd-plugins/
+@so lib/bfd-plugins/libdep.so
 @man man/man1/gaddr2line.1
 @man man/man1/gar.1
 @man man/man1/gc++filt.1
 @comment @man man/man1/gdlltool.1
 @man man/man1/gelfedit.1
+@man man/man1/gld.1
 @man man/man1/gnm.1
 @man man/man1/gobjcopy.1
 @man man/man1/gobjdump.1