-m32 using -triple armv7-unknown-freebsd14.0 leads to attempted usage that involves floating point getting build problems like: ld.lld: error: undefined symbol: __muldf3 . . . did you mean: __muldc3 defined in: /usr/lib32/libgcc_s.so ld.lld: error: undefined symbol: __divdf3 . . . did you mean: __divdc3 defined in: /usr/lib32/libgcc_s.so ld.lld: error: undefined symbol: __ltdf2 . . . devel/llvm* ( or, at least, devel/llvm16+ ) likely should use the correct target for FreeBSD by default as well. For 14.0 that would be -m32 for aarch64 using: -target armv7-unknown-freebsd14.0-gnueabihf Of course, this will generalize to FreeBSD 14.1+ and 15+ as well and to llvm17+ for them. [It may be less certain what should be done for aarch64 FreeBSD versions that do not have lib32. (Less reason to be using -m32.)] I'll note that I would argue that requiring explicit -m32 -target armv7-unknown-freebsd14.0-gnueabihf like notation adds the the using code needing to track 14.x/15+/... as things progress, even when not trying to do a cross build. Even if made automatic, making it so ends up being explicit in more places.
It is probably too late for releng/14.0 to have -m32 automatically use armv7-unknown-freebsd14.0-gnueabihf .
armv7-unknown-freebsd15.0-gnueabihf has the same sort of lack of default use for main as stable/14 and releng/14.? do for armv7-unknown-freebsd14.0-gnueabihf at this point.