Attempting to build bleadperl with gcc-4.8.1-4 downloaded from http://www.mingw.org (using their mingw-get-setup.exe to simply get the current latest version) successfully builds miniperl.exe and a bunch of pure-Perl modules, but then fails on perllib.c when trying to build perl519.dll/perl.exe. The output of the perllib.c compilation is attached. It seems to fail because we have BOOL DllMain(HANDLE, DWORD, LPVOID) in perllib.c, which conflicts with BOOL DllMain(HINSTANCE, DWORD, LPVOID) in mingw/include/winbase.h. I've previously used gcc-4.7.0-1 from http://www.mingw.org and gcc-4.8.0 from http://mingw-w64.sourceforge.net/ (rubenvb's build). These both work fine. Neither one has a declaration of DllMain its winbase.h or anywhere else.

gcc -c -I. -I.\include -I. -I.. -I..\lib\CORE -DWIN32 -DPERLDLL -DPERL_CORE -s -O2 -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_P ERLIO -fno-strict-aliasing -mms-bitfields -xc++ -operllib.o perllib.c perllib.c: In function 'void xs_init(PerlInterpreter*)': perllib.c:37:1: warning: deprecated conversion from string constant to 'char*' [ -Wwrite-strings] char *file = __FILE__; ^ In file included from c:\dev\software\mingw\include\sys\utime.h:35:0, from ./win32iop.h:16, from ./win32.h:623, from ./win32thread.h:4, from ../perl.h:2657, from perllib.c:10: perlhost.h: In function 'CPerlHost* IPerlMem2Host(IPerlMem*)': perlhost.h:247:34: warning: invalid access to non-static data member 'CPerlHost: :m_hostperlMem' of NULL object [-Winvalid-offsetof] return STRUCT2RAWPTR(piPerl, m_hostperlMem); ^ perlhost.h:247:12: note: in expansion of macro 'STRUCT2RAWPTR' return STRUCT2RAWPTR(piPerl, m_hostperlMem); ^ perlhost.h:247:34: warning: (perhaps the 'offsetof' macro was used incorrectly) [-Winvalid-offsetof] return STRUCT2RAWPTR(piPerl, m_hostperlMem); ^ perlhost.h:247:12: note: in expansion of macro 'STRUCT2RAWPTR' return STRUCT2RAWPTR(piPerl, m_hostperlMem); ^ perlhost.h: In function 'CPerlHost* IPerlMemShared2Host(IPerlMem*)': perlhost.h:252:34: warning: invalid access to non-static data member 'CPerlHost: :m_hostperlMemShared' of NULL object [-Winvalid-offsetof] return STRUCT2RAWPTR(piPerl, m_hostperlMemShared); ^ perlhost.h:252:12: note: in expansion of macro 'STRUCT2RAWPTR' return STRUCT2RAWPTR(piPerl, m_hostperlMemShared); ^ perlhost.h:252:34: warning: (perhaps the 'offsetof' macro was used incorrectly) [-Winvalid-offsetof] return STRUCT2RAWPTR(piPerl, m_hostperlMemShared); ^ perlhost.h:252:12: note: in expansion of macro 'STRUCT2RAWPTR' return STRUCT2RAWPTR(piPerl, m_hostperlMemShared); ^ perlhost.h: In function 'CPerlHost* IPerlMemParse2Host(IPerlMem*)': perlhost.h:257:34: warning: invalid access to non-static data member 'CPerlHost: :m_hostperlMemParse' of NULL object [-Winvalid-offsetof] return STRUCT2RAWPTR(piPerl, m_hostperlMemParse); ^ perlhost.h:257:12: note: in expansion of macro 'STRUCT2RAWPTR' return STRUCT2RAWPTR(piPerl, m_hostperlMemParse); ^ perlhost.h:257:34: warning: (perhaps the 'offsetof' macro was used incorrectly) [-Winvalid-offsetof] return STRUCT2RAWPTR(piPerl, m_hostperlMemParse); ^ perlhost.h:257:12: note: in expansion of macro 'STRUCT2RAWPTR' return STRUCT2RAWPTR(piPerl, m_hostperlMemParse); ^ perlhost.h: In function 'CPerlHost* IPerlEnv2Host(IPerlEnv*)': perlhost.h:262:31: warning: invalid access to non-static data member 'CPerlHost: :m_hostperlEnv' of NULL object [-Winvalid-offsetof] return STRUCT2PTR(piPerl, m_hostperlEnv); ^ perlhost.h:240:38: note: in expansion of macro 'STRUCT2RAWPTR' #define STRUCT2PTR(x, y) CheckInterp(STRUCT2RAWPTR(x, y)) ^ perlhost.h:262:12: note: in expansion of macro 'STRUCT2PTR' return STRUCT2PTR(piPerl, m_hostperlEnv); ^ perlhost.h:262:31: warning: (perhaps the 'offsetof' macro was used incorrectly) [-Winvalid-offsetof] return STRUCT2PTR(piPerl, m_hostperlEnv); ^ perlhost.h:240:38: note: in expansion of macro 'STRUCT2RAWPTR' #define STRUCT2PTR(x, y) CheckInterp(STRUCT2RAWPTR(x, y)) ^ perlhost.h:262:12: note: in expansion of macro 'STRUCT2PTR' return STRUCT2PTR(piPerl, m_hostperlEnv); ^ perlhost.h: In function 'CPerlHost* IPerlStdIO2Host(IPerlStdIO*)': perlhost.h:267:31: warning: invalid access to non-static data member 'CPerlHost: :m_hostperlStdIO' of NULL object [-Winvalid-offsetof] return STRUCT2PTR(piPerl, m_hostperlStdIO); ^ perlhost.h:240:38: note: in expansion of macro 'STRUCT2RAWPTR' #define STRUCT2PTR(x, y) CheckInterp(STRUCT2RAWPTR(x, y)) ^ perlhost.h:267:12: note: in expansion of macro 'STRUCT2PTR' return STRUCT2PTR(piPerl, m_hostperlStdIO); ^ perlhost.h:267:31: warning: (perhaps the 'offsetof' macro was used incorrectly) [-Winvalid-offsetof] return STRUCT2PTR(piPerl, m_hostperlStdIO); ^ perlhost.h:240:38: note: in expansion of macro 'STRUCT2RAWPTR' #define STRUCT2PTR(x, y) CheckInterp(STRUCT2RAWPTR(x, y)) ^ perlhost.h:267:12: note: in expansion of macro 'STRUCT2PTR' return STRUCT2PTR(piPerl, m_hostperlStdIO); ^ perlhost.h: In function 'CPerlHost* IPerlLIO2Host(IPerlLIO*)': perlhost.h:272:31: warning: invalid access to non-static data member 'CPerlHost: :m_hostperlLIO' of NULL object [-Winvalid-offsetof] return STRUCT2PTR(piPerl, m_hostperlLIO); ^ perlhost.h:240:38: note: in expansion of macro 'STRUCT2RAWPTR' #define STRUCT2PTR(x, y) CheckInterp(STRUCT2RAWPTR(x, y)) ^ perlhost.h:272:12: note: in expansion of macro 'STRUCT2PTR' return STRUCT2PTR(piPerl, m_hostperlLIO); ^ perlhost.h:272:31: warning: (perhaps the 'offsetof' macro was used incorrectly) [-Winvalid-offsetof] return STRUCT2PTR(piPerl, m_hostperlLIO); ^ perlhost.h:240:38: note: in expansion of macro 'STRUCT2RAWPTR' #define STRUCT2PTR(x, y) CheckInterp(STRUCT2RAWPTR(x, y)) ^ perlhost.h:272:12: note: in expansion of macro 'STRUCT2PTR' return STRUCT2PTR(piPerl, m_hostperlLIO); ^ perlhost.h: In function 'CPerlHost* IPerlDir2Host(IPerlDir*)': perlhost.h:277:31: warning: invalid access to non-static data member 'CPerlHost: :m_hostperlDir' of NULL object [-Winvalid-offsetof] return STRUCT2PTR(piPerl, m_hostperlDir); ^ perlhost.h:240:38: note: in expansion of macro 'STRUCT2RAWPTR' #define STRUCT2PTR(x, y) CheckInterp(STRUCT2RAWPTR(x, y)) ^ perlhost.h:277:12: note: in expansion of macro 'STRUCT2PTR' return STRUCT2PTR(piPerl, m_hostperlDir); ^ perlhost.h:277:31: warning: (perhaps the 'offsetof' macro was used incorrectly) [-Winvalid-offsetof] return STRUCT2PTR(piPerl, m_hostperlDir); ^ perlhost.h:240:38: note: in expansion of macro 'STRUCT2RAWPTR' #define STRUCT2PTR(x, y) CheckInterp(STRUCT2RAWPTR(x, y)) ^ perlhost.h:277:12: note: in expansion of macro 'STRUCT2PTR' return STRUCT2PTR(piPerl, m_hostperlDir); ^ perlhost.h: In function 'CPerlHost* IPerlSock2Host(IPerlSock*)': perlhost.h:282:31: warning: invalid access to non-static data member 'CPerlHost: :m_hostperlSock' of NULL object [-Winvalid-offsetof] return STRUCT2PTR(piPerl, m_hostperlSock); ^ perlhost.h:240:38: note: in expansion of macro 'STRUCT2RAWPTR' #define STRUCT2PTR(x, y) CheckInterp(STRUCT2RAWPTR(x, y)) ^ perlhost.h:282:12: note: in expansion of macro 'STRUCT2PTR' return STRUCT2PTR(piPerl, m_hostperlSock); ^ perlhost.h:282:31: warning: (perhaps the 'offsetof' macro was used incorrectly) [-Winvalid-offsetof] return STRUCT2PTR(piPerl, m_hostperlSock); ^ perlhost.h:240:38: note: in expansion of macro 'STRUCT2RAWPTR' #define STRUCT2PTR(x, y) CheckInterp(STRUCT2RAWPTR(x, y)) ^ perlhost.h:282:12: note: in expansion of macro 'STRUCT2PTR' return STRUCT2PTR(piPerl, m_hostperlSock); ^ perlhost.h: In function 'CPerlHost* IPerlProc2Host(IPerlProc*)': perlhost.h:287:31: warning: invalid access to non-static data member 'CPerlHost: :m_hostperlProc' of NULL object [-Winvalid-offsetof] return STRUCT2PTR(piPerl, m_hostperlProc); ^ perlhost.h:240:38: note: in expansion of macro 'STRUCT2RAWPTR' #define STRUCT2PTR(x, y) CheckInterp(STRUCT2RAWPTR(x, y)) ^ perlhost.h:287:12: note: in expansion of macro 'STRUCT2PTR' return STRUCT2PTR(piPerl, m_hostperlProc); ^ perlhost.h:287:31: warning: (perhaps the 'offsetof' macro was used incorrectly) [-Winvalid-offsetof] return STRUCT2PTR(piPerl, m_hostperlProc); ^ perlhost.h:240:38: note: in expansion of macro 'STRUCT2RAWPTR' #define STRUCT2PTR(x, y) CheckInterp(STRUCT2RAWPTR(x, y)) ^ perlhost.h:287:12: note: in expansion of macro 'STRUCT2PTR' return STRUCT2PTR(piPerl, m_hostperlProc); ^ perllib.c: In function 'BOOL DllMain(HANDLE, DWORD, LPVOID)': perllib.c:296:20: error: declaration of C function 'BOOL DllMain(HANDLE, DWORD, LPVOID)' conflicts with LPVOID lpvReserved) /* reserved */ ^ In file included from c:\dev\software\mingw\include\windows.h:62:0, from ./win32.h:128, from ./win32thread.h:4, from ../perl.h:2657, from perllib.c:10: c:\dev\software\mingw\include\winbase.h:1051:13: error: previous declaration 'BO OL DllMain(HINSTANCE, DWORD, LPVOID)' here BOOL WINAPI DllMain(HINSTANCE, DWORD, LPVOID); ^ dmake: Error code 129, while making 'perllib.o'

On Sat Apr 12 09:07:52 2014, shay wrote: > Attempting to build bleadperl with gcc-4.8.1-4 downloaded from > http://www.mingw.org (using their mingw-get-setup.exe to simply get > the current latest version) successfully builds miniperl.exe and a > bunch of pure-Perl modules, but then fails on perllib.c when trying to > build perl519.dll/perl.exe. > > The output of the perllib.c compilation is attached. > > It seems to fail because we have BOOL DllMain(HANDLE, DWORD, LPVOID) > in perllib.c, which conflicts with BOOL DllMain(HINSTANCE, DWORD, > LPVOID) in mingw/include/winbase.h. > > I've previously used gcc-4.7.0-1 from http://www.mingw.org and gcc- > 4.8.0 from http://mingw-w64.sourceforge.net/ (rubenvb's build). These > both work fine. Neither one has a declaration of DllMain its winbase.h > or anywhere else. The offending declaration was added to winbase.h in version 4 of the w32api package, which is what provides the file. The 4.7.0 installation that I have been using previously was using w32api-3.17. So perllib.c could work around this by declaring DllMain differently when using the new winbase.h, but how to identify it? mingw.org's w32api-3.17 includes a w32api.h with a #define __W32API_VERSION 3.17 in it, but w32api-4.0.3 contains the same (i.e. still saying 3.17) with a note added saying that the header file is now deprecated. Was it replaced by anything? And how do we distinguish mingw.org from mingw-w64.sourceforge.net? (I have seen a way to do the latter, but don't recall it offhand.)

On Sat Apr 12 10:23:34 2014, shay wrote: > On Sat Apr 12 09:07:52 2014, shay wrote: > > Attempting to build bleadperl with gcc-4.8.1-4 downloaded from > > http://www.mingw.org (using their mingw-get-setup.exe to simply get > > the current latest version) successfully builds miniperl.exe and a > > bunch of pure-Perl modules, but then fails on perllib.c when trying > > to > > build perl519.dll/perl.exe. > > > > The output of the perllib.c compilation is attached. > > > > It seems to fail because we have BOOL DllMain(HANDLE, DWORD, LPVOID) > > in perllib.c, which conflicts with BOOL DllMain(HINSTANCE, DWORD, > > LPVOID) in mingw/include/winbase.h. > > > > I've previously used gcc-4.7.0-1 from http://www.mingw.org and gcc- > > 4.8.0 from http://mingw-w64.sourceforge.net/ (rubenvb's build). These > > both work fine. Neither one has a declaration of DllMain its > > winbase.h > > or anywhere else. > > The offending declaration was added to winbase.h in version 4 of the > w32api package, which is what provides the file. The 4.7.0 > installation that I have been using previously was using w32api-3.17. > > So perllib.c could work around this by declaring DllMain differently > when using the new winbase.h, but how to identify it? > > mingw.org's w32api-3.17 includes a w32api.h with a #define > __W32API_VERSION 3.17 in it, but w32api-4.0.3 contains the same (i.e. > still saying 3.17) with a note added saying that the header file is > now deprecated. Was it replaced by anything? And how do we distinguish > mingw.org from mingw-w64.sourceforge.net? (I have seen a way to do the > latter, but don't recall it offhand.) I wondered if we could just switch on "is a www.mingw.org gcc && gcc version is 4.8.0 or higher", but it's not that simple. I tried building with the latest everything except for w32api, which I rolled back to 3.17. That complained that sdkddkver.h, included from _mingw.h in the mingwrt package was now missing, so I rolled mingwrt back too (to 3.20), but still no joy. gcc now has a CreateProcess() error. So far good: it looks like if you're using 4.8+ then you must also have the offending winbase.h declaration so we could switch perl to suit. However, 4.7.2 works with w32api/mingwrt-4.0.3 too and thus has the same problem... but it also works fine with w32api-3.17/mingwrt-3.20, which doesn't have the offending winbase.h declaration and therefore doesn't have the problem. So we need some way of identifying the w32api/mingwrt version. Checking the gcc version isn't good enough since 4.7.2 (at least) can use either "working" or "broken" versions of w32api/mingwrt. And it looks like __MINGW32_VERSION et al in _mingwrt.h could work. In 3.20 it has #define __MINGW32_VERSION 3.20 #define __MINGW32_MAJOR_VERSION 3 #define __MINGW32_MINOR_VERSION 20 #define __MINGW32_PATCHLEVEL 0 while 4.0.3 has #define __MINGW_VERSION 4.0 #define __MINGW_MAJOR_VERSION 4 #define __MINGW_MINOR_VERSION 0 #define __MINGW_PATCHLEVEL 0 Assuming that w32api-3 can't be used with mingwrt-4 or w32api-4 with mingwrt-3 (which I need to check, but I already have that impression from above) then we can indirectly check for the offending w32api by checking if __MINGW_VERION >= 4.0.

On 12.4.2014 19:23, Steve Hay via RT wrote: > On Sat Apr 12 09:07:52 2014, shay wrote: >> Attempting to build bleadperl with gcc-4.8.1-4 downloaded from >> http://www.mingw.org (using their mingw-get-setup.exe to simply get >> the current latest version) successfully builds miniperl.exe and a >> bunch of pure-Perl modules, but then fails on perllib.c when trying to >> build perl519.dll/perl.exe. >> >> The output of the perllib.c compilation is attached. >> >> It seems to fail because we have BOOL DllMain(HANDLE, DWORD, LPVOID) >> in perllib.c, which conflicts with BOOL DllMain(HINSTANCE, DWORD, >> LPVOID) in mingw/include/winbase.h. >> >> I've previously used gcc-4.7.0-1 from http://www.mingw.org and gcc- >> 4.8.0 from http://mingw-w64.sourceforge.net/ (rubenvb's build). These >> both work fine. Neither one has a declaration of DllMain its winbase.h >> or anywhere else. > The offending declaration was added to winbase.h in version 4 of the w32api package, which is what provides the file. The 4.7.0 installation that I have been using previously was using w32api-3.17. > > So perllib.c could work around this by declaring DllMain differently when using the new winbase.h, but how to identify it? > > mingw.org's w32api-3.17 includes a w32api.h with a #define __W32API_VERSION 3.17 in it, but w32api-4.0.3 contains the same (i.e. still saying 3.17) with a note added saying that the header file is now deprecated. Was it replaced by anything? And how do we distinguish mingw.org from mingw-w64.sourceforge.net? (I have seen a way to do the latter, but don't recall it offhand.) Steve, to distinguish mingw.org vs. mingw-w64.sf.net you can use #ifdef __MINGW64_VERSION_MAJOR // mingw-w64.sf.net case #else // mingw.org #endif -- kmx

On Sun Apr 13 13:11:41 2014, [email protected] wrote: > > On 12.4.2014 19:23, Steve Hay via RT wrote: > > On Sat Apr 12 09:07:52 2014, shay wrote: > >> Attempting to build bleadperl with gcc-4.8.1-4 downloaded from > >> http://www.mingw.org (using their mingw-get-setup.exe to simply get > >> the current latest version) successfully builds miniperl.exe and a > >> bunch of pure-Perl modules, but then fails on perllib.c when trying > >> to > >> build perl519.dll/perl.exe. > >> > >> The output of the perllib.c compilation is attached. > >> > >> It seems to fail because we have BOOL DllMain(HANDLE, DWORD, LPVOID) > >> in perllib.c, which conflicts with BOOL DllMain(HINSTANCE, DWORD, > >> LPVOID) in mingw/include/winbase.h. > >> > >> I've previously used gcc-4.7.0-1 from http://www.mingw.org and gcc- > >> 4.8.0 from http://mingw-w64.sourceforge.net/ (rubenvb's build). > >> These > >> both work fine. Neither one has a declaration of DllMain its > >> winbase.h > >> or anywhere else. > > The offending declaration was added to winbase.h in version 4 of the > > w32api package, which is what provides the file. The 4.7.0 > > installation that I have been using previously was using w32api-3.17. > > > > So perllib.c could work around this by declaring DllMain differently > > when using the new winbase.h, but how to identify it? > > > > mingw.org's w32api-3.17 includes a w32api.h with a #define > > __W32API_VERSION 3.17 in it, but w32api-4.0.3 contains the same (i.e. > > still saying 3.17) with a note added saying that the header file is > > now deprecated. Was it replaced by anything? And how do we > > distinguish mingw.org from mingw-w64.sourceforge.net? (I have seen a > > way to do the latter, but don't recall it offhand.) > > Steve, > > to distinguish mingw.org vs. mingw-w64.sf.net you can use > > #ifdef __MINGW64_VERSION_MAJOR > // mingw-w64.sf.net case > #else > // mingw.org > #endif > Thanks. So I gave this a quick whirl and it looks good so far: diff --git a/win32/perllib.c b/win32/perllib.c index 84a618a..6b88094 100644 --- a/win32/perllib.c +++ b/win32/perllib.c @@ -291,7 +291,18 @@ EndSockets(void); EXTERN_C /* GCC in C++ mode mangles the name, otherwise */ #endif BOOL APIENTRY + /* www.mingw.org's mingwrt-4/w32api-4 declares DllMain + * in winbase.h with first parameter as a HINSTANCE */ +#if defined(__MINGW32__) && !defined(__MINGW64__) +#include <_mingw.h> +#if __MINGW_MAJOR_VERSION >= 4 +DllMain(HINSTANCE hModule, /* DLL module handle */ +#else DllMain(HANDLE hModule, /* DLL module handle */ +#endif +#else +DllMain(HANDLE hModule, /* DLL module handle */ +#endif DWORD fdwReason, /* reason called */ LPVOID lpvReserved) /* reserved */ { but then I realized that the MSDN documentation of DllMain actually specifies HINSTANCE rather than HANDLE anyway: http://msdn.microsoft.com/en-us/library/ms682583.aspx so in fact www.mingw.org's w32api-4 is correct, and it's perl that's wrong. The following much simpler patch is also going well so far, and I now intend to commit this if it builds without complaint with all flavours of gcc and cl: diff --git a/win32/perllib.c b/win32/perllib.c index 84a618a..cd1c11a 100644 --- a/win32/perllib.c +++ b/win32/perllib.c @@ -291,7 +291,7 @@ EndSockets(void); EXTERN_C /* GCC in C++ mode mangles the name, otherwise */ #endif BOOL APIENTRY -DllMain(HANDLE hModule, /* DLL module handle */ +DllMain(HINSTANCE hModule, /* DLL module handle */ DWORD fdwReason, /* reason called */ LPVOID lpvReserved) /* reserved */ {

On Mon Apr 14 10:20:07 2014, shay wrote: > The following much simpler patch is also going well so far, and I now > intend to commit this if it builds without complaint with all flavours > of gcc and cl: > > diff --git a/win32/perllib.c b/win32/perllib.c > index 84a618a..cd1c11a 100644 > --- a/win32/perllib.c > +++ b/win32/perllib.c > @@ -291,7 +291,7 @@ EndSockets(void); > EXTERN_C /* GCC in C++ mode mangles the name, otherwise > */ > #endif > BOOL APIENTRY > -DllMain(HANDLE hModule, /* DLL module handle */ > +DllMain(HINSTANCE hModule, /* DLL module handle */ > DWORD fdwReason, /* reason called */ > LPVOID lpvReserved) /* reserved */ > { Now applied in commit a5d1065d95. However, this ticket should stay open until another problem in cpan/Win32 is fixed: https://rt.cpan.org/Ticket/Display.html?id=94730

On Mon Apr 14 15:21:00 2014, shay wrote: > On Mon Apr 14 10:20:07 2014, shay wrote: > > The following much simpler patch is also going well so far, and I now > > intend to commit this if it builds without complaint with all > > flavours > > of gcc and cl: > > > > diff --git a/win32/perllib.c b/win32/perllib.c > > index 84a618a..cd1c11a 100644 > > --- a/win32/perllib.c > > +++ b/win32/perllib.c > > @@ -291,7 +291,7 @@ EndSockets(void); > > EXTERN_C /* GCC in C++ mode mangles the name, > > otherwise > > */ > > #endif > > BOOL APIENTRY > > -DllMain(HANDLE hModule, /* DLL module handle */ > > +DllMain(HINSTANCE hModule, /* DLL module handle */ > > DWORD fdwReason, /* reason called */ > > LPVOID lpvReserved) /* reserved */ > > { > > Now applied in commit a5d1065d95. > > However, this ticket should stay open until another problem in > cpan/Win32 is fixed: > > https://rt.cpan.org/Ticket/Display.html?id=94730 Now fixed in Win32-0.49 (thanks to Jan Dubois for a speedy response!) and applied in commit 7432779b54. The build now works, but oddly fails one test: C:\Dev\Git\perl\t>..\perl harness ../ext/POSIX/t/time.t ../ext/POSIX/t/time.t .. 1/19 # Failed test 'difftime()' # at t/time.t line 87. # got: '2' # expected: '1' # Looks like you failed 1 test of 19. ../ext/POSIX/t/time.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/19 subtests (less 2 skipped subtests: 16 okay) Test Summary Report ------------------- ../ext/POSIX/t/time.t (Wstat: 256 Tests: 19 Failed: 1) Failed test: 17 Non-zero exit status: 1 Files=1, Tests=19, 0 wallclock secs ( 0.00 usr + 0.02 sys = 0.02 CPU) Result: FAIL The test in question is simply: is(difftime(2, 1), 1, "difftime()"); How on earth it thinks the difference between 1 and 2 is 2 rather than 1, I do not know. Testing it some more, it appears that POSIX::difftime(x, y) returns x for any x and y! This is not the case with other gcc builds, even from www.mingw.org, AFAIK. I will investigate further, but we could be heading for just skipping this test for this compiler or else logging as a Known Problem...

On Tue Apr 15 13:32:12 2014, shay wrote: > The build now works, but oddly fails one test: > > C:\Dev\Git\perl\t>..\perl harness ../ext/POSIX/t/time.t > ../ext/POSIX/t/time.t .. 1/19 > # Failed test 'difftime()' > # at t/time.t line 87. > # got: '2' > # expected: '1' > # Looks like you failed 1 test of 19. > ../ext/POSIX/t/time.t .. Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/19 subtests > (less 2 skipped subtests: 16 okay) > > Test Summary Report > ------------------- > ../ext/POSIX/t/time.t (Wstat: 256 Tests: 19 Failed: 1) > Failed test: 17 > Non-zero exit status: 1 > Files=1, Tests=19, 0 wallclock secs ( 0.00 usr + 0.02 sys = 0.02 > CPU) > Result: FAIL > > The test in question is simply: > > is(difftime(2, 1), 1, "difftime()"); > > How on earth it thinks the difference between 1 and 2 is 2 rather than > 1, I do not know. > > Testing it some more, it appears that POSIX::difftime(x, y) returns x > for any x and y! This is not the case with other gcc builds, even from > www.mingw.org, AFAIK. I will investigate further, but we could be > heading for just skipping this test for this compiler or else logging > as a Known Problem... This seems to be a bug in some MinGW builds, so I will simply log it as a Known Problem, I think. (It's probably more trouble than it's worth to attempt to pin-point exactly which versions fail and skip the test for those versions.) http://sourceforge.net/p/mingw/bugs/2152/

On Wed Apr 16 06:12:30 2014, shay wrote: > On Tue Apr 15 13:32:12 2014, shay wrote: > > The build now works, but oddly fails one test: > > > > C:\Dev\Git\perl\t>..\perl harness ../ext/POSIX/t/time.t > > ../ext/POSIX/t/time.t .. 1/19 > > # Failed test 'difftime()' > > # at t/time.t line 87. > > # got: '2' > > # expected: '1' > > # Looks like you failed 1 test of 19. > > ../ext/POSIX/t/time.t .. Dubious, test returned 1 (wstat 256, 0x100) > > Failed 1/19 subtests > > (less 2 skipped subtests: 16 okay) > > > > Test Summary Report > > ------------------- > > ../ext/POSIX/t/time.t (Wstat: 256 Tests: 19 Failed: 1) > > Failed test: 17 > > Non-zero exit status: 1 > > Files=1, Tests=19, 0 wallclock secs ( 0.00 usr + 0.02 sys = 0.02 > > CPU) > > Result: FAIL > > > > The test in question is simply: > > > > is(difftime(2, 1), 1, "difftime()"); > > > > How on earth it thinks the difference between 1 and 2 is 2 rather > > than > > 1, I do not know. > > > > Testing it some more, it appears that POSIX::difftime(x, y) returns x > > for any x and y! This is not the case with other gcc builds, even > > from > > www.mingw.org, AFAIK. I will investigate further, but we could be > > heading for just skipping this test for this compiler or else logging > > as a Known Problem... > > This seems to be a bug in some MinGW builds, so I will simply log it > as a Known Problem, I think. (It's probably more trouble than it's > worth to attempt to pin-point exactly which versions fail and skip the > test for those versions.) > > http://sourceforge.net/p/mingw/bugs/2152/ Note now added by commit 80ccccdff59107c4ba712244ad455a3e1fcb4929.