libc.so.0 => ... ld64-uClibc.so.0 => ...
Samples from systems for developing pattern matches should not be truncated... if the data is sensitive or very long, it can be obfuscated or have its char class substrings shortened.
Some forums and mail can mangle chars classes outside isalnum(3), tab, space, newlines, control, wrapping, etc... in which case some safer encoding or file transmission may be useful...
ldd | openssl base64 -e
grep 'libc.'
to
grep '\slibc.'
1) Grep's conformant to at least this standard do not support '\s' regarding whitespace...
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html
Nor do all systems comply to any particular least common standard, or have their man pages current with the code itself...
https://www.freebsd.org/cgi/man.cgi https://www.kernel.org/doc/man-pages/
regex, wctype, grep, sed, awk, tr, etc...
Perhaps try...
ldd /usr/bin/yes | sed -r 's,^[[:space:]]+,,' | awk '/^libc./ {print $1}'
2) configure.ac:119:dnl Get libc full system path. ...
The function returns only the basename, not the full path, so 119 should say something else.
3) The function may not have a case for the OP's system, and assumes the input and text processing pipestream is and acts the same between Linux* and FreeBSD* systems. That gap and assumption should be checked.
4) The "default" shipped with latest FreeBSD release (12.x) is libc.so.7 not libc.so.6 which would then also fail if the parsing fails.
5) FreeBSD 12.x
ldd /usr/bin/yes | openssl base64 -e L3Vzci9iaW4veWVzOgoJbGliYy5zby43ID0+IC9saWIvbGliYy5zby43ICgweDgw MDI0OTAwMCkK