In two places, the hardcoded name was used instead, and this was
interferring with cross compilation.

Yes, `ar` itself is target-agnostic, so it is easy for hard-coded `ar`s
to slip in. But it is also normal to not have `ar` available when one
only has a cross, not native, toolchain on the path. Consistently using
the tool variables, as is done for the other tools, and the object file
archiver also elsewhere (`${AR}` is already in use), is the proper
idiom.
---
 share/mk/bsd.lib.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk
index 9cf9ffdf8e6..91b8650eef6 100644
--- a/share/mk/bsd.lib.mk
+++ b/share/mk/bsd.lib.mk
@@ -226,10 +226,10 @@ ${FULLSHLIBNAME}: ${SOBJS} ${DPADD}
 .endif
 
 ${FULLSHLIBNAME}.a: ${SOBJS}
-	@echo building shared ${LIB} library \(version ${SHLIB_MAJOR}.${SHLIB_MINOR}\) ar
+	@echo building shared ${LIB} library \(version ${SHLIB_MAJOR}.${SHLIB_MINOR}\) ${AR}
 	@rm -f ${.TARGET}
 	@echo -Wl,-soname,${FULLSHLIBNAME} ${PICFLAG} ${LDADD} > .ldadd
-	ar cqD ${FULLSHLIBNAME}.a ${SOBJS} .ldadd ${SYMBOLSMAP}
+	${AR} cqD ${FULLSHLIBNAME}.a ${SOBJS} .ldadd ${SYMBOLSMAP}
 
 # all .do files...
 DOBJS+=	${OBJS:.o=.do}
-- 
2.42.0