Windows build failure with www.mingw.org's gcc-4.8.1-4 #13733
Comments
From @steve-m-hayAttempting 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. |
From @steve-m-haygcc -c -I. -I.\include -I. -I.. -I..\lib\CORE -DWIN32 -DPERLDLL -DPERL_CORE -s |
From @steve-m-hayOn Sat Apr 12 09:07:52 2014, shay wrote:
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.) |
From @steve-m-hayOn Sat Apr 12 10:23:34 2014, shay wrote:
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 while 4.0.3 has #define __MINGW_VERSION 4.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. |
From @kmxOn 12.4.2014 19:23, Steve Hay via RT wrote:
Steve, to distinguish mingw.org vs. mingw-w64.sf.net you can use #ifdef __MINGW64_VERSION_MAJOR -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @steve-m-hayOn Sun Apr 13 13:11:41 2014, kmx@atlas.cz wrote:
Thanks. So I gave this a quick whirl and it looks good so far: Inline Patchdiff --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 */
{
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 Patchdiff --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 */
{ |
From @steve-m-hayOn Mon Apr 14 10:20:07 2014, shay wrote:
Now applied in commit a5d1065. However, this ticket should stay open until another problem in cpan/Win32 is fixed: |
From @steve-m-hayOn Mon Apr 14 15:21:00 2014, shay wrote:
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 Test Summary Report ../ext/POSIX/t/time.t (Wstat: 256 Tests: 19 Failed: 1) 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... |
|
@steve-m-hay - Status changed from 'open' to 'resolved' |
From @steve-m-hayOn Tue Apr 15 13:32:12 2014, shay wrote:
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/ |
From @steve-m-hayOn Wed Apr 16 06:12:30 2014, shay wrote:
Note now added by commit 80ccccd. |
Migrated from rt.perl.org#121643 (status was 'resolved')
Searchable as RT121643$
The text was updated successfully, but these errors were encountered: