Hi,
When building a test package shared in
https://savannah.gnu.org/bugs/?57406
(https://haible.de/bruno/gnu/testdir-posix-mingw.tar.gz) with my
mingw/clang/libc++ based toolchain, I ran into some errors in the gltests
subdirectory.
One of the issues looks like this:
../gllib/string.h:920:19: error: no member named 'strndup' in the global
namespace; did you mean 'strdup'?
_GL_CXXALIAS_SYS (strndup, char *, (char const *__s, size_t __n));
~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/sys/socket.h:269:20: note: expanded from macro '_GL_CXXALIAS_SYS'
return ::func; \
~~^
../gllib/string.h:872:19: note: 'strdup' declared here
_GL_CXXALIASWARN (strdup);
^
../gllib/string.h:920:1: error: cannot initialize return object of type
'gnulib::_gl_strndup_wrapper::type' (aka 'char *(*)(const char *, unsigned
long long)') with an lvalue of type 'typeof (strdup)' (aka 'char *(const
char *)'): different number of parameters (2 vs 1)
_GL_CXXALIAS_SYS (strndup, char *, (char const *__s, size_t __n));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/sys/socket.h:269:18: note: expanded from macro '_GL_CXXALIAS_SYS'
return ::func; \
^~~~~~
../gllib/string.h:922:19: error: use of undeclared identifier 'strndup';
did you mean 'strdup'?
_GL_CXXALIASWARN (strndup);
^
../gllib/string.h:872:19: note: 'strdup' declared here
_GL_CXXALIASWARN (strdup);
^
The root cause for this issue seems to be that clang has a builtin for the
strndup function, even if the target platform actually doesn't have it.
This manifests itself during configure like this:
configure:31903: checking whether strndup is declared
configure:31903: x86_64-w64-mingw32-gcc -c -g -O2 conftest.c >&5
conftest.c:267:10: warning: implicitly declaring library function
'strndup' with type 'char *(const char *, unsigned long long)'
[-Wimplicit-function-declaration]
(void) strndup;
^
conftest.c:267:10: note: include the header <string.h> or explicitly
provide a declaration for 'strndup'
1 warning generated.
configure:31903: $? = 0
configure:31903: result: yes
This results in variables set up like this:
ac_cv_func_strndup=no
ac_cv_have_decl_strndup=yes
GNULIB_STRNDUP = 1
HAVE_DECL_STRNDUP = 1
REPLACE_STRNDUP = 0
Which then leads to the errors quoted above. I presume this is a case of
an unexpected combination of flags that lead to this situation, which
makes the gnulib string.h (when included from C++) produce this error.
I guess one could argue that one should fix clang not to expose builtins
for things the target platforms doesn't support though, but given these
configure test results, is this something that gnulib could react to
differently?
// Martin
