When lld is /usr/bin/ld (WITH_LLD_IS_LD in src.conf) seabios fails to build due to a test for an old binutils ld issue:
The version of LD on this system (ld) does not properly handle
alignments. As a result, this project can not be built.
The problem may be the result of this LD bug report:
Please update to a working version of binutils and retry.
Normally we can use LLD_UNSAFE=yes in the ports Makefile which sets LD=ld.bfd and adds -fuse-ld=bfd to LDFLAGS, but seabios's Makefile doesn't honour LD set from the environment because it overrides it with:
FWIW lld also fails to link the test case, but I suspect the failure is not the same as the old binutils issue. I do not know if lld can successfully link seabios. lld's error (from the invocation in scripts/test-build.sh) is:
ld.lld: error: tmp/tmp_testcompile1.lds:4: unable to move location counter backward for: .mysection
Sabios already requires Gcc in order to compile, so I would just set USE_BINUTILS=yes to force it to use GNU ld.
It fails with MAKE_BINUTILS as well, for the same reason; seabios ignores any attempt to specify the linker and just uses ld found in $PATH.
Created attachment 189198 [details]
Conditionally set tools path
I think something like this should work in order to pick the variables defined in the environment. I can send this upstream if it solves our issues.
seabios builds for me with that patch, with lld as /usr/bin/ld and LLD_UNSAFE=yes in the port's Makefile
Created attachment 191758 [details]
Force GNU ld usage
Via tobik@ in ports r465725, BINARY_ALIAS=ld=ld.bfd may be an effective workaround if LLD_UNSAFE does not work.
Oh, so it's better to use LLD_UNSAFE rather than USE_BINUTILS and setting LD?
I thought the proposed approach was better because it's exactly the same that SeaBIOS already uses in order to compile with GCC (USE_GCC and pass HOSTCC=... in the make rune).
> Oh, so it's better to use LLD_UNSAFE rather than USE_BINUTILS and setting LD?
Either approach should work; I just went through all "failing with lld as /usr/bin/ld" PRs that were still open and added this info as a possible workaround in case other approaches weren't working.
I think your argument for the approach in your patch is fine and as the maintainer you should choose anyhow :-)
Should be fixed by r466430.