Bug #124844 for Time-HiRes: Build failure with module bundled with Perl 5.27.10

Hello and thank you for your work, I tried to build Perl 5.27.10 on a 64 bit Windows 10 machine with Visual Studio 2017 with the provided Makefile, and the build failed because HiRes.xs failed to compile with the errors: HiRes.xs(1325): error C2079: 'Tz' uses undefined struct 'timezone' HiRes.xs(1344): error C2079: 'Tz' uses undefined struct 'timezone' HiRes.xs(1360): error C2079: 'Tz' uses undefined struct 'timezone' Changes mentions this: https://metacpan.org/changes/distribution/Time-HiRes#L3 1.9577 [2018-03-15] - fix win32 (and cygwin?) builds which have been broken since 1.9755: problem was that gettimeofday() is a macro and needs to stay such First, I believe the version number for this release in Changes is a typo. It should be 1.9757. It seems to me that this is a case of assuming gcc on Windows. See earlier reports: http://www.cpantesters.org/cpan/report/d099a63a-6cb1-1014-9853-f25910f5bab9 http://www.cpantesters.org/cpan/report/be353111-6c2a-1014-bdf0-8ac521104667 http://www.cpantesters.org/cpan/report/d099a63a-6cb1-1014-9853-f25910f5bab9 http://www.cpantesters.org/cpan/report/431b4d4b-6c26-1014-a8bb-9841a16ecb65 I am Cc'ing P5P on this because I believe 5.27.10 is the RC for 5.28. -- Sinan

Thank you. Please note that Time::HiRes 1.9758 fixes the issue. https://metacpan.org/source/JHI/Time-HiRes-1.9758/Changes#L3

On Wed, Mar 21, 2018 at 6:29 PM, A. Sinan Unur <sinan@unur.com> wrote: Show quoted text
Well, it puts on a band-aid for one compiler but doesn't really fix the fundamental problem. Other compilers can't even compile blead at what is supposed to be a pretty late state of code freeze. How many other compilers/run-times/platforms know (or don't know) about struct timezone? The standard says that the second argument to gettimeofday is of type pointer to void: <http://pubs.opengroup.org/onlinepubs/9699919799/> and I have been unable to find any standard that defines struct timezone or the settimeofday function. If Time::HiRes wants to prefer a platform-specific, non-standard struct that may or may not be defined in sys/time.h, then it owns the problem of detecting whether the compiler/runtime being used to build it has that struct available. It would be risky to add such detection during code freeze, but it's downright churlish to blithely assume something like this exists without bothering to check.