On Sun, Dec 21, 2025 at 12:40:05PM +0000, Klemens Nanni wrote: > 21.12.2025 15:26, Jeremie Courreges-Anglas пишет: [...] > > 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. > > Fixing it would be up to me as maintainer, if that doesn't go anywhere > we could always mark such leaf ports as BROKEN so as not to block progress.
Marking such ports as BROKEN would indeed be the right move, but it doesn't have to be that way. > > All of this disappears if you use cross-compiling with a stable > > toolchain like u-boot does. > > Wouldn't it require ld.bfd still which devel/arm-none-eabi/gcc/ lacks? > > Regardless of cross-compilation, amd64 does and will require native tools > from devel/binutils, so I don't see a way around building ld.bfd there. See my reply to the ipxe port, it seems you missed devel/arm-none-eabi/binutils. -- jca
