On Thu, Feb 19, 2026 at 05:47:19PM +0200, Eli Zaretskii wrote: > > Date: Thu, 19 Feb 2026 16:34:14 +0100 > > From: Patrice Dumas <[email protected]> > > Cc: Gavin Smith <[email protected]>, [email protected] > > > > > I tried including <string.h>, but that didn't help, although the > > > Gnulib version of strndup is compiled and I see it in libgnu.a, and it > > > seems to be declared in Gnulib's string.h. Not sure what am I missing > > > here. Any ideas? > > > > The convert/call_html_perl_function.c file is not compiled with Gnulib > > headers, as it is compiled with Perl headers and they are incompatible. > > Accordingly, there is no #include <config.h>. However, adding <string.h> > > is supposed to work and is included in other similar files such as > > tta/C/main/build_perl_info.c, so why including <string.h> does not help > > eludes me. > > Because MinGW doesn't have strndup, so the system headers don't define > its prototype. Which Perl header file declares strndup? I searched > all of the header files in the Perl tree, and didn't find any that > declared strndup.
I may be totally off, but my feeling is that if there are include files that are missing, as is the case on Windows, Perl defines the function itself probably with a preprocessor macro that changes the function name, and provides the functions in libperl. > But if this file links against Gnulib's libgnu.a, why doesn't it > include the Gnulib headers? That's inconsistent, no? We do not include the Gnulib headers because Perl headers already do something, and something inconsistent with Gnulib headers. Then we assume that what Perl and Gnulib do adds some kind of name spacing such that it is possible to link against both libgnu.a and perllib without inconsistencies, providing that we use the correct functions consistently. > > Something that comes to me is that the libc includes are > > before the Perl includes, before the comment /* Avoid namespace conflicts. > > */ > > maybe you added the include later on, and it could matter? > > No, I added it before that. Maybe strndup is not defined/redefined by Perl at all, then. In that case, maybe a solution could be to use our own Perl-compatible strndup implementation, which is the perl_only_strndup function. I think that the use of strndup in C code built against Perl headers is quite new, it is possible that we never had code like that before. -- Pat
