The alternative linker for the 32bit compat is a "hack" while LLD doesn't fully support powerpc32. So I did it in a different file to avoid mixing a "hack" with regular logic.

It's defined by in Makefile.libcompat.inc1 and passed to 'stand' by Makefile.inc1 through CROSSENV variable.

I don't think we need a separate file for this. Especially the name is confusing if it is powerpc-specific. We have plenty of hacks already in both Makefile.inc1 and Makefile.libcompat that are arch-specific.

This will fail when compiled stand alone outside of buildworld.

Where is HOST_ARCH defined? Grep has no hits and make -V HOST_ARCH produces an empty string.

Replaced by _HOST_ARCH.

LIB32LD will be passed to stand either through buildworld or by first performing a 'make buildenv' before changing to stand and trying to build it.

But when trying to build stand without calling buildenv first, LIB32LD will be undefined.
In this case I chose to report an error, informing that LIB32LD must be set when stand is built with clang on powerpc64.

Is that ok? If not, what would be the alternative? Put the LIB32LD detection code in a separate make file that could be included by stand/defs.mk?

No. I'd say that's not OK. It's almost never OK to have .error statements based on things not being defined. there's too many use cases to know you covered them all.

Please don't use TARGET_ARCH. It's incorrect here since this is included from both Makefile.inc1 and from individual makefiles.

Instead, please follow the (new) convention of the rest of the file and use COMPAT_ARCH since it does the proper dance.

LIB32LD still isn't defined in a file that gets included in the build.
Defining it all in bsd.compat.mk seems fundamentally wrong to me. that's not really what that's for.
If you want to use those things in the rest of the build, you'd need to define it bsd.cpu.mk (which bsd.compat.mk has access to).

this hard wires the *HOSTS* current /usr/bin/ld.bfd. That's not right. It should be the one in the sysroot, even for native builds.

we know COMPAT_ARCH is defined here, and that it necessarily equals powerpc64.

we know 100% that COMPAT_ARCH is powerpc64 here, maybe you have a nesting issue?

I'm having trouble seeing when this would be true given the full paths.
And full paths, btw, aren't a documented option for -fuse-ld in the gcc docs I found online

Here -fuse-ld will be used when *not* using GCC. Clang implemented full paths after https://reviews.llvm.org/D17952.

Shouldn't this just be

.if ${COMPAT_COMPILER_TYPE} == "gcc"

Right now CROSS_BINUTILS_PREFIX is defined only in Makefile.inc1, which I don't think exports this variable to the dependent make processes... I'm also unsure how this would work in a standalone build on a powerpc platform...
It's likely OK enough since most people don't do builds on native powerpc platforms outside of a buildworld, but that's supposed to work and may not w/o setting this variable by hand...

Case "LD_BFD=${LOCALBASE}/bin/${CROSS_BINUTILS_PREFIX}-ld.bfd" seems to cover the native build. The correct linker path being passed to clang in my tests.

Regarding CROSS_BINUTILS_PREFIX, it's defined in the standard toolchain file (i.e: pkg install "powerpc64-xtoolchain-gcc-0.4_1" on amd64). That's the case I would like to cover

I'm not sure "in tree" build is covered here. But it can be handled after flagday, or it may not be needed in the near future, since ld.lld full support for PowerPC32 bit is almost complete and this LD_BFD workaround is temporary.