In torsocks' configure.ac, libc_name is determined by means of ldd /usr/bin/yes which is then grepped for libc.
On a uClibc system I use, ldd /usr/bin/yes yields two entries, namely
libc.so.0 => ... ld64-uClibc.so.0 => ...
The resulting string begins with quotation mark, ends with quotation mark and contains newline character.
At some point during the configuration process (I have not figured out when exactly), the aforementioned string is trimmed erroneously. In my case, the first line is left out and the second one is discarded. The remaining chunk, with the opening quotation mark but without the closing one, ends up in another configuration file, producing a line like
SOME_VARIABLE="libc.so.0
without the closing quotation mark. Build cannot proceed from there.
The libc determination process thus needs to be fixed.
My hotfix was to change
grep 'libc.'
to
grep '\slibc.'
but I can't suggest the proper solution as I'm not experienced with shell scripts. I will perform a test if provided with (a link to) a relevant standalone patch for torsocks-2.2.0 or torsocks-2.3.0.
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