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
Win32 MinGW build failure #15446
Comments
From @dcollinsnHello, I have acquired both MinGW and MinGW64 versions of gcc. Here are the gcc -v and CCHOME from makefile.mk for each: 32 bit: 64 bit: Compiling the 32 bit version fails quite early: gcc -c -I.\include -I. -I.. -DWIN32 -DWIN64 -DCONSERVATIVE -DPERLDLL -DPERL_CORE -s -O2 -fwrapv -fno-strict-aliasing -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -omini\toke.o ..\toke.c The 64 bit version uses this command, which compiles successfully: gcc -c -I.\include -I. -I.. -DWIN32 -DWIN64 -DCONSERVATIVE -DPERLDLL -DPERL_CORE -s -O2 -fwrapv -fno-strict-aliasing -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -omini\toke.o ..\toke.c -- |
From @dcollinsnCorrection: in fact, the current value of CCHOME on the 64 bit makefile is: CCHOME *= C:\mingw-w64\i686-4.9.3\mingw32 -- |
From @sisyphus-----Original Message----- # New Ticket Created by Dan Collins
What version of perl were you trying to build ? What version of the mingw runtime does the failing toolchain use Cheers, |
The RT System itself - Status changed from 'new' to 'open' |
From @dcollinsnCurrent blead, commit 8bfa1b5. Happy to try any older commit if you wish #define __MINGW32_VERSION 3022000L On Fri, Jul 15, 2016 at 10:33 PM, Sisyphus via RT <perlbug-followup@perl.org
|
From @sisyphusFrom: Dan Collins
I think you'll find the problem has been around for a while. But mingw.org have managed to ensure that the problem arises in 3.22. I do, however, still get the failure building building Scalar::List::Util No-one seems to be using minw.org compilers for building 32-bit perl any
A portable fix would depend upon determining whether the behaviour changed #if __MINGW64_VERSION_MAJOR >= 4 to something like #if __MINGW64_VERSION_MAJOR >= 4 || (__MINGW32_MAJOR_VERSION == 3 && That should be portable because mingw.org compilers don't define But was the original fix effected by amending config_H.gc only ? ... or are Cheers, |
From @sisyphus-----Original Message-----
Rather, more like: #if __MINGW64_VERSION_MAJOR >= 4 || __MINGW32_MAJOR_VERSION > 3 || But I should leave that formulation to people who can think clearly ;-) Cheers, |
From @dcollinsnI can't find an obvious way to download an older mingw setup to test with. While the HAS_MKSTEMP macro in config_H.gc is nice and all, win32.h #if !defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 4 I tried: #if (!defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 4) && And that worked. For a little while, at least. Guess I needed to choose to -- On Sat, Jul 16, 2016 at 12:05 AM, Sisyphus via RT <perlbug-followup@perl.org
|
From @dcollinsnI spoke too soon - win32.c ALSO uses the bad macro On Sat, Jul 16, 2016 at 12:38 AM, Dan Collins <dcollinsn@gmail.com> wrote:
|
From @sisyphusFrom: Dan Collins
Duh ... hardly surprising that win32.c and win32.h (and not just
No - but I did find that mkstemp() became available as of runtime version At Keith Marshall (mingw.org lead developer) volunteered the following info: So ... my "|| __MINGW32_MAJOR_VERSION > 3" condition can (and should) be Cheers, |
From @dur-randirCreated by @dur-randirMingw compiler toolchain from mingw.org is explicitly listed as 1) 2) Perl Info
|
From @steve-m-hayI've just run into this bug, testing blead with recent mingw.org compilers - 5.3.0 and 6.3.0. Previously I have used 4.8.1 and haven't seen the problem. It revolves around which version of the MinGW runtime library is being used. My 4.8.1 installation reports __MINGW32_MAJOR_VERSION=3 despite coming from a file looking like it's version 4 (mingwrt-4.0.3-1-mingw32-dev.tar.lzma), so I guess it just missed the cut for mkstemp() addition. But my 5.3.0 and 6.3.0 installations use newer runtimes: __MINGW32_MAJOR_VERSION=5 (the former from mingwrt-5.0-mingw32-dev.tar.xz and the latter from mingwrt-5.0.2-mingw32-dev.tar.xz) which do include mkstemp(). I think we need something like f33b2f5 to fix it, but switching on the #defines above. Trouble is, I don't know what numbers to use because of the confusing message from Keith Marshall (via Sisyphus) above. Does anyone know what version is reported by "the fatally flawed mingwrt-4.x variants" reported? Is that what my 4.8.1 setup is using, despite reporting itself as 3.20? Or are there versions that report themselves as 4.x? I've only just discovered that new mingw.org compilers (v5 and v6) even exist. But knowing this now, I wonder if this should be a 5.28 blocker? |
This comment has been minimized.
This comment has been minimized.
From @sisyphusOn Thu, 10 May 2018 05:58:06 -0700, shay wrote:
My take regarding 4.x is that all we need to do is assume that mkstemp() is not defined for runtimes that report __MINGW32_MAJOR_VERSION as 4 - and code accordingly.
Fiddling with it now could be a little risky in that mingw-w64 compilers also define __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSIO - and UIM we definitely don't want them to start doing things differently. I've checked my mingw-w64 compilers from 4.7.0 through to 7.2.0, and __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION are always 3 and 11. It's __MINGW64_VERSION_MAJOR, __MINGW64_VERSION_MINOR that correctly identify their runtime version numbers. Cheers, |
From @sisyphusOn Thu, 10 May 2018 05:58:06 -0700, shay wrote:
Ignoring my better judgement, I installed mingw.org's 6.3.0 compiler and tried to build perl-5.27.11. win32sck.c: In function 'win32_select': When I take a look at the pertinent winsock.h, I find the following pedantic drivel: /********************************/ #else /* _WINSOCK_ANOMALOUS_TYPEDEFS */ typedef struct fd_set FD_SET, *PFD_SET, *LPFD_SET; So ... at line 570 of GNUmakefile I added -D_WINSOCK_ANOMALOUS_TYPEDEFS to the defines: DEFINES = -DWIN32 -D_WINSOCK_ANOMALOUS_TYPEDEFS That unleashes a shitload of warnings elicited by the above code, but at least the damn thing then builds ok until we get to: ####################### At that point it became a case of either throwing a brick through the console, or walking away. Back last century, I was a big fan of mingw.org's work. Cheers, |
From @bulk88On Thu, 10 May 2018 05:58:06 -0700, shay wrote:
I consider only strawberry perl released GCCs to be the pool of ones that have mandatory support. Strawberry originally used mingw.org, but pretty quickly switched to mingw64 and stuck with that ever since. Although most of mingw isn't maintained by either group RCS wise, mingw.org less supported and used. Might as well call it ReactOS. Nice if it works, but nobody uses it in production. I suspect far more FOSS unixy projects are tested on mingw64 and shipped as binaries than with mingw.org so finding random header problems (one of the few parts of the src code both groups fully 100% control), wouldnt surprise me. -- |
From @steve-m-hayOn 11 May 2018 at 14:56, sisyphus@cpan.org via RT
I didn't realize things were so bad in the new (v5.3.0 and v6.3.0) Even v4.8.1 doesn't work overly well - I also see warnings (not I think I will let this go since it's looking like more trouble than Similar problems were also reported in [perl #133041] for v6.3.0. I |
From @steve-m-hayThanks for the report. This was also reported in [perl #128631], which I will attempt to merge this into. I think the answer is going to be that only v3.4.5 to v4.x are now supported. The original MinGW compilers are not very reliable after that and may be too much trouble to try to support. The MinGW-w64 compilers are the way to go these days. |
The RT System itself - Status changed from 'new' to 'open' |
From @steve-m-hay
I've now updated the documentation, in commit |
@steve-m-hay I think documentation is all that can be done in this case, right? |
Migrated from rt.perl.org#128631 (status was 'open')
Searchable as RT128631$
The text was updated successfully, but these errors were encountered: