This is needed on GCC versions older than 10 (e.g. GCC 9).
No objections, this makes sense to me.
I'll kick off a test on my end with the gcc9 toolchain.
Are you sure about that? The libcompat stage re-includes bsd.cpu.mk with the new MACHINE_ARCH value. It's true that some settings don't persist for things that use NEED_COMPAT such as the rtld-elf32 build, all the library builds will honor this.
Or is the question about libraries shipped with the compiler itself? For the devel/freebsd-gccX ports, we don't ship libstdc++ or the like but instead use the base system libcompiler_rt and libc++ as they are intended to be used as system compilers.
In PR 239007 you mentioned that you did a backport of the patch for gcc which brings secure-plt. But you also found that adding -msecure-plt to CFLAGS.gcc is doing its job. For powerpc gcc that might work, but if you build a powerpc64 gcc with multilibs, with 32-bit libgcc etc., then I doubt that this is enough. But I might be wrong.
So I do have the patch relative to freebsd-gcc9 and if that is the preferred route I can commit that instead of this change. This change should pass -msecure-plt to the powepc64-gcc compiler when building lib32 and it should pass -msecure-plt to the powerpc-gcc compiler when building a powerpc world. Does that help clear things up? I mostly did this route to minimize the patches I had to carry in the freebsd-gcc9 port, but I'm open to whatever approach the powerpc folks prefer.
I would prefer that the bsd.cpu.mk change go in even if the compiler defaults are fixed as well, so that it will still do the right thing when using an unpatched gcc.
The bsd.cpu.mk change will only fix 32-bit native, not 64-bit -> 32bit lib build. The right fix is to backport the patch from PR239007 to gcc-8 and gcc-9. I expect one release for gcc-8 and at least one for gcc-9. I try to take care to upstream and to feed the ports tree with a intermediate patch for gcc8/9-(devel).