Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows build failure with www.mingw.org's gcc-4.8.1-4 #13733

Closed
p5pRT opened this issue Apr 12, 2014 · 12 comments

Comments

@p5pRT
Copy link
Collaborator

commented Apr 12, 2014

Migrated from rt.perl.org#121643 (status was 'resolved')

Searchable as RT121643$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 12, 2014

From @steve-m-hay

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.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 12, 2014

From @steve-m-hay

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'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 12, 2014

From @steve-m-hay

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.)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 12, 2014

From @steve-m-hay

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.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 13, 2014

From @kmx

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 13, 2014

The RT System itself - Status changed from 'new' to 'open'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 14, 2014

From @steve-m-hay

On Sun Apr 13 13​:11​:41 2014, kmx@​atlas.cz 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​:

Inline Patch
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​:

Inline Patch
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 */
 {
@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 14, 2014

From @steve-m-hay

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 a5d1065.

However, this ticket should stay open until another problem in cpan/Win32 is fixed​:

https://rt.cpan.org/Ticket/Display.html?id=94730

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 15, 2014

From @steve-m-hay

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 a5d1065.

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 7432779.

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...

@p5pRT p5pRT closed this Apr 15, 2014
@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 15, 2014

@steve-m-hay - Status changed from 'open' to 'resolved'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 16, 2014

From @steve-m-hay

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/

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

commented May 23, 2014

From @steve-m-hay

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 80ccccd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.