configure doesn't detect strerror_r() in uClibc

[dirkf]

In GNU-ish systems, there are two versions of strerror_r(): the standard version and the GNU version. In a particular target system with uClibc (read-only), the technique used by autoconf to verify that a system function is available fails because the identifier strerror_r is not an entry-point in the C library: instead, it is defined through <string.h> to either __xpg_strerror_r or __glibc_strerror_r depending on feature macros. autoconf's test program doesn't include <string.h>, which is good in one way, as that would result in incompatible declarations, but of course equally its reference to strerror_r() is invalid.

The autoconf manual says that its underlying strategy is that programs should be written using standard APIs and the role of autoconf is to discover which used APIs are missing so that they can be shimmed. However the approach (as implemented by the function check macro in the package) fails since each API is only meaningful in the context of its mandated header file(s).

Because of the conflicting definitions of strerror_r(), it is recommended to avoid using it, so avoiding the above problem.

[ueno]

Although it's a bit overkill, we generally prefer strerror_l over the other variants, which are only used in a fallback path. Perhaps we should emulate the former without relying on strerror_r.