On 05/19/2017 04:40 PM, Eli Zaretskii wrote: >> Cc: gdb-patc...@sourceware.org, Thomas Schwinge <tho...@codesourcery.com> >> From: Pedro Alves <pal...@redhat.com> >> Date: Fri, 19 May 2017 16:22:55 +0100 >> >> But then, xstrndup.c has at the top: >> >> #ifdef HAVE_STRING_H >> #include <string.h> >> #else >> # ifdef HAVE_STRINGS_H >> # include <strings.h> >> # endif >> #endif >> >> So I would expect your build to pick the strnlen declaration from >> one of the string.h or strings.h mingw headers. Why didn't it? > > Because MinGW doesn't have it, not unless you build a program that > will require one of the newer versions of the Windows C runtime > library. That's why libiberty's strnlen is being compiled in the > MinGW build in the first place.
OK, I didn't realize there was a strnlen replacement too. > > Specifically, the MinGW headers do provide a prototype for strnlen if > the program defines __MSVCRT_VERSION__ to be a high enough version, or > defines _POSIX_C_SOURCE >= 200809L, but none of these is set by > default, and is not a good idea, as explained above, for a program > that needs to run on a wide variety of OS versions. > > IOW, libiberty shouldn't rely on the system headers to provide a > strnlen prototype when libiberty's strnlen is being included in the > library as a replacement. OK, I guess then we're up to figuring out which direction to go. Either an AC_CHECK_DECL is missing on libiberty's configure, or the original patch really wanted AC_CHECK_FUNC instead of AC_CHECK_DECL. Or something else, I only look at libiberty's configury every couple of years and forget how this is all supposed to work in between. Thanks, Pedro Alves
