On Gentoo I am unable to compile 0ad when I am using musl-libc.
It fails with the following error:
../../../source/third_party/cppformat/format.cpp: In function 'int fmt::internal::safe_strerror(int, char*&, std::size_t)': ../../../source/third_party/cppformat/format.cpp:435:29: error: invalid conversion from 'int' to 'char*' [-fpermissive] char *message = strerror_r(error_code, buffer, buffer_size);
strerror(3) says that "char *strerror_r()" is specific to GNU, and "int strerror_r()" should be XSI-compliant, which I believe is also the case with musl-libc.
This patch will change the strerror_r() call to strerror() in order to keep it being a char pointer, and still allow compilation on non-glibc (in this case musl-libc) systems.
Excerpt from the manpage:
strerror_r()
The strerror_r() function is similar to strerror(), but is thread safe. This function is available in two
versions: an XSI-compliant version specified in POSIX.1-2001 (available since glibc 2.3.4, but not POSIX-com‐
pliant until glibc 2.13), and a GNU-specific version (available since glibc 2.0). The XSI-compliant version
is provided with the feature test macros settings shown in the SYNOPSIS; otherwise the GNU-specific version is
provided. If no feature test macros are explicitly defined, then (since glibc 2.4) _POSIX_C_SOURCE is defined
by default with the value 200112L, so that the XSI-compliant version of strerror_r() is provided by default.
The XSI-compliant strerror_r() is preferred for portable applications. It returns the error string in the
user-supplied buffer buf of length buflen.
The GNU-specific strerror_r() returns a pointer to a string containing the error message. This may be either
a pointer to a string that the function stores in buf, or a pointer to some (immutable) static string (in
which case buf is unused). If the function stores a string in buf, then at most buflen bytes are stored (the
string may be truncated if buflen is too small and errnum is unknown). The string always includes a terminat‐
ing null byte ('\0').