[tor-dev] torsocks configure bug (uClibc, maybe other nonstandard libcs)

[grarpamp]

> 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