flockfile undefined on Mingw64 platform

[Daniel P. Berrange]

I'm trying to build libvirt with the latest GNULIB git master, on Mingw64
platform (Fedora 25 based).

I get compile warnings:

getopt.c: In function 'process_long_option':
getopt.c:281:5: warning: implicit declaration of function 'flockfile' [-Wimplicit-function-declaration]
flockfile (stderr);
^~~~~~~~~
getopt.c:295:5: warning: implicit declaration of function 'funlockfile' [-Wimplicit-function-declaration]
funlockfile (stderr);
^~~~~~~~~~~
gettimeofday.c:42:1: warning: 'initialize' defined but not used [-Wunused-function]
initialize (void)
^~~~~~~~~~


and then link failures


../gnulib/lib/.libs/libgnu.a(getopt.o): In function `process_long_option':
/home/berrange/src/virt/libvirt/gnulib/lib/getopt.c:281: undefined reference to `flockfile'
/home/berrange/src/virt/libvirt/gnulib/lib/getopt.c:295: undefined reference to `funlockfile'
collect2: error: ld returned 1 exit status
Makefile:6361: recipe for target 'libvirt.la' failed


Looks like this is probably caused by this:

commit dcfe5a0e9cae998ae4e6480f357ff4af5e60fdf8
Author: Zack Weinberg <***@panix.com>
Date: Thu Apr 6 11:14:14 2017 -0700

getopt: clean up error reporting

getopt can print a whole bunch of error messages, and when used
standalone (from gnulib) it uses fprintf to do that. But fprintf is a
cancellation point and getopt isn't, and also applying fprintf to a
stream in wide-character mode is not allowed. So every single error
reporting case has an #ifdef _LIBC block in which it calls internal
libc functions instead. The counterpart patch series in glibc makes
it possible to simplify all of that down to a set of #defines at the
top of the file; core code is written as if it is safe to just call
fprintf, flockfile, and funlockfile. (One caveat: it's *not* safe to
call any *other* stdio functions.)

* lib/getopt.c: When _LIBC is defined, define fprintf to
__fxprintf_nocancel, flockfile to _IO_flockfile, and funlockfile
to _IO_funlockfile. When neither _LIBC nor
_POSIX_THREAD_SAFE_FUNCTIONS is defined, define flockfile and
funlockfile as no-ops.
(_getopt_internal_r): Remove all internal #ifdef _LIBC blocks; the
standalone error-printing code can now be used for libc as well.
Add an flockfile/funlockfile pair around one case where the error
message is printed in several chunks. Don't use fputc.

That code defines flockfile/funlockfile to no-ops, when
_POSIX_THREAD_SAFE_FUNCTIONS is *not* defined.

Unfortunately Mingw defines it in time.h and pthread_unistd.h, but does
*not* provide flockfile afaict.

Regards,
Daniel

[Bruno Haible]

Post by Daniel P. Berrange
gettimeofday.c:42:1: warning: 'initialize' defined but not used [-Wunused-function]
initialize (void)
^~~~~~~~~~

Should be fixed through the gettimeofday change of today.

Post by Daniel P. Berrange
I'm trying to build libvirt with the latest GNULIB git master, on Mingw64
platform (Fedora 25 based).
getopt.c:281:5: warning: implicit declaration of function 'flockfile' [-Wimplicit-function-declaration]
flockfile (stderr);
^~~~~~~~~
getopt.c:295:5: warning: implicit declaration of function 'funlockfile' [-Wimplicit-function-declaration]
funlockfile (stderr);
^~~~~~~~~~~

I'll leave this to Paul and/or Zack, because of the special situation of
getopt.c between glibc and gnulib.

FYI, this is the third report after
https://lists.gnu.org/archive/html/bug-gnulib/2017-04/msg00068.html
and
https://lists.gnu.org/archive/html/bug-gnulib/2017-04/msg00150.html

Bruno

[Paul Eggert]

I'm really the wrong person to be fixing this sort of thing since I
don't use MS-Windows. However, I installed a getopt workaround that I
hope is obvious, here:

http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=19fb4184b097eee0f17f16bdd40d60e3e6d91d45

Perhaps Zack can comment when he finds the time, as he knowsthis part of
the code better.

[Daniel P. Berrange]

I'm really the wrong person to be fixing this sort of thing since I don't
use MS-Windows. However, I installed a getopt workaround that I hope is
http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=19fb4184b097eee0f17f16bdd40d60e3e6d91d45
Perhaps Zack can comment when he finds the time, as he knowsthis part of the
code better.

Thanks, that solves the build issue for me at least.

Regards,
Daniel