Skip Menu |
Report information
Id: 128631
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: dcollinsn [at] gmail.com
randir <sergey.aleynikov [at] gmail.com>
Cc:
AdminCc:

Operating System: Win32
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



Subject: Win32 MinGW build failure
Hello, I have acquired both MinGW and MinGW64 versions of gcc. Here are the gcc -v and CCHOME from makefile.mk for each: 32 bit: CCHOME *= C:\MinGW C:\Users\dcollins>C:\MinGW\bin\gcc -v Using built-in specs. COLLECT_GCC=C:\MinGW\bin\gcc COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.9.3/lto-wrapper.exe Target: mingw32 Configured with: ../src/gcc-4.9.3/configure --build=x86_64-pc-linux-gnu --host=mingw32 --prefix=/mingw --disable-win32-registry --target=mingw32 --with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-libstdcxx-debug --with-tune=generic --enable-nls Thread model: win32 gcc version 4.9.3 (GCC) 64 bit: CCHOME *= C:\MinGW\mingw64 # Changed to support install directory C:\Users\dcollins>C:\mingw-w64\i686-4.9.3\mingw32\bin\gcc -v Using built-in specs. COLLECT_GCC=C:\mingw-w64\i686-4.9.3\mingw32\bin\gcc COLLECT_LTO_WRAPPER=C:/mingw-w64/i686-4.9.3/mingw32/bin/../libexec/gcc/i686-w64-mingw32/4.9.3/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: ../../../src/gcc-4.9.3/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/c/mingw493/i686-493-posix-dwarf-rt_v4-rev1/mingw32 --with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-sjlj-exceptions --with-dwarf2 --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=i686 --with-tune=generic --with-libiconv --with-system-zlib --with-gmp=/c/mingw493/prerequisites/i686-w64-mingw32-static --with-mpfr=/c/mingw493/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw493/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw493/prerequisites/i686-w64-mingw32-static --with-cloog=/c/mingw493/prerequisites/i686-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='i686-posix-dwarf-rev1, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw493/i686-493-posix-dwarf-rt_v4-rev1/mingw32/opt/include -I/c/mingw493/prerequisites/i686-zlib-static/include -I/c/mingw493/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw493/i686-493-posix-dwarf-rt_v4-rev1/mingw32/opt/include -I/c/mingw493/prerequisites/i686-zlib-static/include -I/c/mingw493/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw493/i686-493-posix-dwarf-rt_v4-rev1/mingw32/opt/lib -L/c/mingw493/prerequisites/i686-zlib-static/lib -L/c/mingw493/prerequisites/i686-w64-mingw32-static/lib -Wl,--large-address-aware' Thread model: posix gcc version 4.9.3 (i686-posix-dwarf-rev1, Built by MinGW-W64 project) 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 In file included from ..\perl.h:3205:0, from ..\toke.c:40: ./win32.h:363:13: error: conflicting types for 'mkstemp' extern int mkstemp(const char *path); ^ In file included from ..\perl.h:781:0, from ..\toke.c:40: c:\mingw\include\stdlib.h:796:30: note: previous definition of 'mkstemp' was here __cdecl __MINGW_NOTHROW int mkstemp (char *__filename_template) ^ 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 -- Respectfully, Dan Collins
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 150b
Correction: in fact, the current value of CCHOME on the 64 bit makefile is: CCHOME *= C:\mingw-w64\i686-4.9.3\mingw32 -- Respectfully, Dan Collins
Subject: Re: [perl #128631] Win32 MinGW build failure
From: <sisyphus1 [...] optusnet.com.au>
Date: Sat, 16 Jul 2016 12:31:38 +1000
To: <perl5-porters [...] perl.org>, <bugs-bitbucket [...] rt.perl.org>
Download (untitled) / with headers
text/plain 1.3k
Show quoted text
-----Original Message----- From: Dan Collins (via RT) Sent: Saturday, July 16, 2016 11:54 AM To: bugs-bitbucket@rt.perl.org Subject: [perl #128631] Win32 MinGW build failure # New Ticket Created by Dan Collins # Please include the string: [perl #128631] # in the subject line of all future correspondence about this issue. # <URL: https://rt.perl.org/Ticket/Display.html?id=128631 >
> 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 > In file included from ..\perl.h:3205:0, > from ..\toke.c:40: > ./win32.h:363:13: error: conflicting types for 'mkstemp' > extern int mkstemp(const char *path); > ^ > In file included from ..\perl.h:781:0, > from ..\toke.c:40: > c:\mingw\include\stdlib.h:796:30: note: previous definition of 'mkstemp' > was here > __cdecl __MINGW_NOTHROW int mkstemp (char *__filename_template)
^ Looks like this one has raised its head again: http://www.nntp.perl.org/group/perl.perl5.porters/2015/05/msg227963.html What version of perl were you trying to build ? What version of the mingw runtime does the failing toolchain use (__MINGW32_VERSION_MAJOR and __MINGW32_VERSION_MINOR) ? Cheers, Rob
Date: Fri, 15 Jul 2016 22:42:14 -0400
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
Subject: Re: [perl #128631] Win32 MinGW build failure
From: Dan Collins <dcollinsn [...] gmail.com>
Download (untitled) / with headers
text/plain 1.7k
Current blead, commit 8bfa1b588. Happy to try any older commit if you wish to isolate the issue.


#define __MINGW32_VERSION           3022000L
#define __MINGW32_MAJOR_VERSION           3
#define __MINGW32_MINOR_VERSION          22
#define __MINGW32_PATCHLEVEL              0



On Fri, Jul 15, 2016 at 10:33 PM, Sisyphus via RT <perlbug-followup@perl.org> wrote:
Show quoted text
-----Original Message-----
From: Dan Collins (via RT)
Sent: Saturday, July 16, 2016 11:54 AM
To: bugs-bitbucket@rt.perl.org
Subject: [perl #128631] Win32 MinGW build failure

# New Ticket Created by  Dan Collins
# Please include the string:  [perl #128631]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=128631 >


> 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
> In file included from ..\perl.h:3205:0,
>                 from ..\toke.c:40:
> ./win32.h:363:13: error: conflicting types for 'mkstemp'
> extern  int mkstemp(const char *path);
>             ^
> In file included from ..\perl.h:781:0,
>                 from ..\toke.c:40:
> c:\mingw\include\stdlib.h:796:30: note: previous definition of 'mkstemp'
> was here
>  __cdecl __MINGW_NOTHROW  int mkstemp (char *__filename_template)
                              ^
Looks like this one has raised its head again:
http://www.nntp.perl.org/group/perl.perl5.porters/2015/05/msg227963.html

What version of perl were you trying to build ?

What version of the mingw runtime does the failing toolchain use
(__MINGW32_VERSION_MAJOR and __MINGW32_VERSION_MINOR) ?

Cheers,
Rob



To: "Dan Collins" <dcollinsn [...] gmail.com>, "Perl RT Bug Tracker" <perlbug-followup [...] perl.org>
Date: Sat, 16 Jul 2016 13:54:10 +1000
Subject: Re: [perl #128631] Win32 MinGW build failure
From: <sisyphus1 [...] optusnet.com.au>
Download (untitled) / with headers
text/plain 1.7k
From: Dan Collins Sent: Saturday, July 16, 2016 12:42 PM To: Perl RT Bug Tracker Subject: Re: [perl #128631] Win32 MinGW build failure Show quoted text
> Current blead, commit 8bfa1b588. Happy to try any older commit if you wish > to isolate the issue.
I think you'll find the problem has been around for a while. IIUC, the original fix worked on the assumption that this problem would not arise unless major version was at least 4. But mingw.org have managed to ensure that the problem arises in 3.22. My mingw.org compiler uses runtime 3.20, and that failure does not arise when I use it to build current git (same commit as you used). I do, however, still get the failure building building Scalar::List::Util (#128438). No-one seems to be using minw.org compilers for building 32-bit perl any more. (For that, we're all apparently using 32-bit compilers from the mingw-w64 team.) Show quoted text
> #define __MINGW32_VERSION 3022000L > #define __MINGW32_MAJOR_VERSION 3 > #define __MINGW32_MINOR_VERSION 22 > #define __MINGW32_PATCHLEVEL 0
A portable fix would depend upon determining whether the behaviour changed in 3.21 or 3.22. And the condition in win32/config_H.gc would then(assuming the behaviour changed with 3.22) change from: #if __MINGW64_VERSION_MAJOR >= 4 to something like #if __MINGW64_VERSION_MAJOR >= 4 || (__MINGW32_MAJOR_VERSION == 3 && _MINGW32_MINOR_VERSION > 21) That should be portable because mingw.org compilers don't define __MINGW64_VERSION_MAJOR and mingw-w64 compilers (both 32-bit and 64-bit) don't define __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION But was the original fix effected by amending config_H.gc only ? ... or are there other files affected, too ? Cheers, Rob
Date: Sat, 16 Jul 2016 14:03:49 +1000
To: "Dan Collins" <dcollinsn [...] gmail.com>, "Perl RT Bug Tracker" <perlbug-followup [...] perl.org>
Subject: Re: [perl #128631] Win32 MinGW build failure
From: <sisyphus1 [...] optusnet.com.au>
Download (untitled) / with headers
text/plain 533b
Show quoted text
-----Original Message----- From: sisyphus1@optusnet.com.au Sent: Saturday, July 16, 2016 1:54 PM To: Dan Collins ; Perl RT Bug Tracker Subject: Re: [perl #128631] Win32 MinGW build failure
> #if __MINGW64_VERSION_MAJOR >= 4 || (__MINGW32_MAJOR_VERSION == 3 && > _MINGW32_MINOR_VERSION > 21)
Rather, more like: #if __MINGW64_VERSION_MAJOR >= 4 || __MINGW32_MAJOR_VERSION > 3 || (__MINGW32_MAJOR_VERSION == 3 && _MINGW32_MINOR_VERSION > 21) But I should leave that formulation to people who can think clearly ;-) Cheers, Rob
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
Subject: Re: [perl #128631] Win32 MinGW build failure
From: Dan Collins <dcollinsn [...] gmail.com>
Date: Sat, 16 Jul 2016 00:38:56 -0400
Download (untitled) / with headers
text/plain 1.3k
I can't find an obvious way to download an older mingw setup to test with. Can you?

While the HAS_MKSTEMP macro in config_H.gc is nice and all, win32.h contains:

#if !defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 4
extern  int mkstemp(const char *path);
#endif

I tried:

#if (!defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 4) && (!defined(__MINGW32_MAJOR_VERSION) || __MINGW32_MAJOR_VERSION < 3 || (__MINGW32_MAJOR_VERSION == 3 && __MINGW32_MINOR_VERSION < 22))

And that worked. For a little while, at least. Guess I needed to choose to install gcc-c++ as well. Will let you know if there are any issues, in the mean time patching win32.h to use the HAS_MKSTEMP that you described sounds like the best fix to me.

--
Dan



On Sat, Jul 16, 2016 at 12:05 AM, Sisyphus via RT <perlbug-followup@perl.org> wrote:
Show quoted text
-----Original Message-----
From: sisyphus1@optusnet.com.au
Sent: Saturday, July 16, 2016 1:54 PM
To: Dan Collins ; Perl RT Bug Tracker
Subject: Re: [perl #128631] Win32 MinGW build failure

> #if __MINGW64_VERSION_MAJOR >= 4 || (__MINGW32_MAJOR_VERSION == 3 &&
> _MINGW32_MINOR_VERSION > 21)

Rather, more like:

#if __MINGW64_VERSION_MAJOR >= 4 || __MINGW32_MAJOR_VERSION > 3 ||
(__MINGW32_MAJOR_VERSION == 3 && _MINGW32_MINOR_VERSION > 21)

But I should leave that formulation to people who can think clearly ;-)

Cheers,
Rob



From: Dan Collins <dcollinsn [...] gmail.com>
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
Subject: Re: [perl #128631] Win32 MinGW build failure
Date: Sat, 16 Jul 2016 00:48:07 -0400
Download (untitled) / with headers
text/plain 1.5k
I 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:
Show quoted text
I can't find an obvious way to download an older mingw setup to test with. Can you?

While the HAS_MKSTEMP macro in config_H.gc is nice and all, win32.h contains:

#if !defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 4
extern  int mkstemp(const char *path);
#endif

I tried:

#if (!defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 4) && (!defined(__MINGW32_MAJOR_VERSION) || __MINGW32_MAJOR_VERSION < 3 || (__MINGW32_MAJOR_VERSION == 3 && __MINGW32_MINOR_VERSION < 22))

And that worked. For a little while, at least. Guess I needed to choose to install gcc-c++ as well. Will let you know if there are any issues, in the mean time patching win32.h to use the HAS_MKSTEMP that you described sounds like the best fix to me.

--
Dan



On Sat, Jul 16, 2016 at 12:05 AM, Sisyphus via RT <perlbug-followup@perl.org> wrote:
-----Original Message-----
From: sisyphus1@optusnet.com.au
Sent: Saturday, July 16, 2016 1:54 PM
To: Dan Collins ; Perl RT Bug Tracker
Subject: Re: [perl #128631] Win32 MinGW build failure

> #if __MINGW64_VERSION_MAJOR >= 4 || (__MINGW32_MAJOR_VERSION == 3 &&
> _MINGW32_MINOR_VERSION > 21)

Rather, more like:

#if __MINGW64_VERSION_MAJOR >= 4 || __MINGW32_MAJOR_VERSION > 3 ||
(__MINGW32_MAJOR_VERSION == 3 && _MINGW32_MINOR_VERSION > 21)

But I should leave that formulation to people who can think clearly ;-)

Cheers,
Rob




Subject: Re: [perl #128631] Win32 MinGW build failure
From: <sisyphus1 [...] optusnet.com.au>
To: "Dan Collins" <dcollinsn [...] gmail.com>, "Perl RT Bug Tracker" <perlbug-followup [...] perl.org>
Date: Sat, 16 Jul 2016 16:49:50 +1000
From: Dan Collins Sent: Saturday, July 16, 2016 2:48 PM To: Perl RT Bug Tracker Subject: Re: [perl #128631] Win32 MinGW build failure Show quoted text
> I spoke too soon - win32.c ALSO uses the bad macro
Duh ... hardly surprising that win32.c and win32.h (and not just config_H.gc) need some attention ;-) Show quoted text
> On Sat, Jul 16, 2016 at 12:38 AM, Dan Collins <dcollinsn@gmail.com> wrote: > > I can't find an obvious way to download an older mingw setup to test with. > Can you?
No - but I did find that mkstemp() became available as of runtime version 3.21. At http://stackoverflow.com/questions/6036227/mkstemp-implementation-for-win32 Keith Marshall (mingw.org lead developer) volunteered the following info: [quote] For the record, MinGW.org now provide mkstemp() and mkdtemp(), in releases of the MinGW runtime library, mingwrt-3.21 and later, (but not in the fatally flawed mingwrt-4.x variants, which have now been withdrawn from general release). [end quote] So ... my "|| __MINGW32_MAJOR_VERSION > 3" condition can (and should) be removed. Cheers, Rob
To: perlbug [...] perl.org
Subject: 32-bit original mingw build is broken
From: Sergey Aleynikov <sergey.aleynikov [...] gmail.com>
Date: Thu, 29 Mar 2018 02:31:54 +0300
Download (untitled) / with headers
text/plain 4.8k
This is a bug report for perl from sergey.aleynikov@gmail.com, generated with the help of perlbug 1.41 running under perl 5.27.11. ----------------------------------------------------------------- [Please describe your issue here] Mingw compiler toolchain from mingw.org is explicitly listed as supported in README.win32. But when I tried to build blead with it, I've got the following two errors: 1) if not exist ".\mini" mkdir ".\mini" copy config_H.gc config.h 1 file(s) copied. rem. > .\mini\.exists gcc -c -I.\include -I. -I.. -DWIN32 -DPERLDLL -DPERL_CORE -s -O2 -fwrapv -fno-strict-aliasing -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -omini\toke.o ..\toke.c In file included from ..\perl.h:2937:0, from ..\toke.c:40: ./win32.h:416:13: error: conflicting types for 'mkstemp' extern int mkstemp(const char *path); ^~~~~~~ In file included from ..\perl.h:819:0, from ..\toke.c:40: c:\mingw\include\stdlib.h:809:30: note: previous definition of 'mkstemp' was here __cdecl __MINGW_NOTHROW int mkstemp (char *__filename_template) ^~~~~~~ dmake: Error code 129, while making 'mini\toke.o' 2) gcc -c -I.\include -I. -I.. -DWIN32 -DPERLDLL -DPERL_CORE -s -O2 -fwrapv -fno-strict-aliasing -DPERL_IS_MINIPERL -omini\win32sck.o win32sck.c win32sck.c: In function 'win32_select': win32sck.c:494:12: error: expected ';' before 'nrd' FD_SET nrd, nwr, nex; ^~~ In file included from c:\mingw\include\winsock2.h:62:0, from c:\mingw\include\ws2spi.h:36, from win32sck.c:19: win32sck.c:499:14: error: 'nrd' undeclared (first use in this function) FD_ZERO(&nrd); ^ win32sck.c:499:14: note: each undeclared identifier is reported only once for each function it appears in win32sck.c:500:14: error: 'nwr' undeclared (first use in this function) FD_ZERO(&nwr); ^ win32sck.c:501:14: error: 'nex' undeclared (first use in this function) FD_ZERO(&nex); ^ dmake: Error code 129, while making 'mini\win32sck.o' [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=medium --- Site configuration information for perl 5.27.11: Configured by dur-randir at Thu Mar 29 01:47:29 2018. Summary of my perl5 (revision 5 version 27 subversion 11) configuration: Platform: osname=MSWin32 osvers=6.1.7601 archname=MSWin32-x86-perlio uname='' config_args='undef' hint=recommended useposix=true d_sigaction=undef useithreads=undef usemultiplicity=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='gcc' ccflags =' -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -fwrapv -fno-strict-aliasing -mms-bitfields' optimize='-s -O2' cppflags='-DWIN32' ccversion='' gccversion='6.3.0' gccosandvers='' intsize=4 longsize=4 ptrsize=4 doublesize=8 byteorder=1234 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=12 longdblkind=3 ivtype='long' ivsize=4 nvtype='double' nvsize=8 Off_t='long long' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='g++' ldflags ='-s -L"c:\perl\lib\CORE" -L"C:\MinGW\lib"' libpth=C:\MinGW\lib libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 libc= so=dll useshrplib=true libperl=libperl527.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs dlext=dll d_dlsymun=undef ccdlflags=' ' cccdlflags=' ' lddlflags='-mdll -s -L"c:\perl\lib\CORE" -L"C:\MinGW\lib"' --- @INC for perl 5.27.11: lib c:/perl-git-false/lib --- Environment for perl 5.27.11: HOME (unset) LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\perl\bin;C:\Program Files (x86)\AMD\ATI.ACE\Core-Static;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Git\cmd;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\PowerShell\6.0.1\;;c:\dmake;c:\MinGW\mingw64\bin;c:\MinGW\mingw32\bin;c:\MinGW\bin PERL_BADLANG (unset) SHELL (unset)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.3k
I'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 __MINGW32_MINOR_VERSION=20 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 __MINGW32_MINOR_VERSION=0 (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 https://perl5.git.perl.org/perl.git/commit/f33b2f585292653a3c50ea39cbdab734c3473fcb 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?
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.4k
On Thu, 10 May 2018 05:58:06 -0700, shay wrote: Show quoted text
> > 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?
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. Show quoted text
> 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?
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. However, mingw-w64 compilers seem to always define those values as "3" and "11" respectively and that would mean we could fiddle with __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION without altering mingw-w64 behaviour (because we're not going to mess with anything less than 3.21, right ?). 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. However, I haven't checked for every mingw-w64 compiler. What are the chances ? Cheers, Rob
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 3.6k
On Thu, 10 May 2018 05:58:06 -0700, shay wrote: Show quoted text
> I've only just discovered that new mingw.org compilers (v5 and v6) > even exist.
Ignoring my better judgement, I installed mingw.org's 6.3.0 compiler and tried to build perl-5.27.11. However, after working around the problem involving mkstemp (which is easy enough, for some definition of "easy enough"), I then get hammered with: win32sck.c: In function 'win32_select': win32sck.c:494:12: erreur: expected ';' before 'nrd' FD_SET nrd, nwr, nex; When I take a look at the pertinent winsock.h, I find the following pedantic drivel: /********************************/ #ifndef FD_SET #if !_WINSOCK_ANOMALOUS_TYPEDEFS /* WinSock is intended to mimic the Berkeley Sockets API, for which * POSIX.1 provides a reference specification; this states that FD_SET * may be implemented as either a macro, or as a function. The reference * <winsock.h> implementation at http://www.sockets.com/winsock.htm#WinsockH * includes a typedef for FD_SET, which a) conflicts with the latter POSIX.1 * provision, and b) creates potential confusion with the former. Thus, we * prefer to conform with POSIX.1 functional semantics, and recommend that * users avoid the potentially confusing FD_SET typedefs, so allowing us * to provide this function prototype: */ void FD_SET (SOCKET, fd_set *); #else /* _WINSOCK_ANOMALOUS_TYPEDEFS */ /* However, for users who insist on eschewing standard C/C++ syntax, and * for whatever reason must use FD_SET as a data type, instead of correctly * referring to fd_set, or for pointer references, use PFD_SET or LPFD_SET * instead of standard fd_set * references, we make these anomalous types * visible, when the _WINSOCK_ANOMALOUS_TYPEDEFS feature test macro is * defined with a non-zero value. */ #warning "FD_SET, PFD_SET, and LPFD_SET data types are non-portable." #warning "Use portable fd_set, and fd_set * type references instead." typedef struct fd_set FD_SET, *PFD_SET, *LPFD_SET; #endif #define FD_SET( __fd, __set ) __FD_SET ((__fd), (__set)) __CRT_ALIAS void __FD_SET (SOCKET __fd, fd_set *__set) { if( (__set->fd_count < FD_SETSIZE) && ! FD_ISSET (__fd, __set) ) __set->fd_array[__set->fd_count++] = __fd; } #endif /* ! defined FD_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: ####################### APItest.o:APItest.c:(.text+0x5c83): undefined reference to `_imp__Perl_to_utf8_title' APItest.o:APItest.c:(.text+0xb293): undefined reference to `_imp__Perl_to_utf8_upper' APItest.o:APItest.c:(.text+0xb9e3): undefined reference to `_imp__Perl_to_utf8_fold' APItest.o:APItest.c:(.text+0xc2d3): undefined reference to `_imp__Perl_to_utf8_lower' collect2.exe: erreur: ld a retourné 1 code d'état d'exécution Makefile:483: recipe for target '..\..\lib\auto\XS\APItest\APItest.dll' failed gmake[1]: *** [..\..\lib\auto\XS\APItest\APItest.dll] Error 1 gmake[1]: Leaving directory 'C:/_32/mingw32_new_comp/perl-5.27.11/ext/XS-APItest ' Unsuccessful make(ext/XS-APItest): code=512 at ..\make_ext.pl line 570. GNUmakefile:1578: recipe for target 'Extensions' failed make: *** [Extensions] Error 2 ####################### At that point it became a case of either throwing a brick through the console, or walking away. Wisely, I decided to walk away. Perhaps I can return to it later. Back last century, I was a big fan of mingw.org's work. But, these days, I find it not in the least surprising that they're being deserted in favour of the mingw-w64 compilers. Cheers, Rob
RT-Send-CC: perl5-porters [...] perl.org
On Thu, 10 May 2018 05:58:06 -0700, shay wrote: Show quoted text
> I'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 > __MINGW32_MINOR_VERSION=20 > > 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 > __MINGW32_MINOR_VERSION=0 > > (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 > > https://perl5.git.perl.org/perl.git/commit/f33b2f585292653a3c50ea39cbdab734c3473fcb > > 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?
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. -- bulk88 ~ bulk88 at hotmail.com
Date: Mon, 14 May 2018 14:07:25 +0100
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
CC: perl5-porters [...] perl.org
Subject: Re: [perl #128631] Win32 MinGW build failure
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 4.5k
On 11 May 2018 at 14:56, sisyphus@cpan.org via RT <perlbug-followup@perl.org> wrote: Show quoted text
> On Thu, 10 May 2018 05:58:06 -0700, shay wrote: >
>> I've only just discovered that new mingw.org compilers (v5 and v6) >> even exist.
> > Ignoring my better judgement, I installed mingw.org's 6.3.0 compiler and tried to build perl-5.27.11. > However, after working around the problem involving mkstemp (which is easy enough, for some definition of "easy enough"), I then get hammered with: > > win32sck.c: In function 'win32_select': > win32sck.c:494:12: erreur: expected ';' before 'nrd' > FD_SET nrd, nwr, nex; > > When I take a look at the pertinent winsock.h, I find the following pedantic drivel: > > /********************************/ > #ifndef FD_SET > #if !_WINSOCK_ANOMALOUS_TYPEDEFS > /* WinSock is intended to mimic the Berkeley Sockets API, for which > * POSIX.1 provides a reference specification; this states that FD_SET > * may be implemented as either a macro, or as a function. The reference > * <winsock.h> implementation at http://www.sockets.com/winsock.htm#WinsockH > * includes a typedef for FD_SET, which a) conflicts with the latter POSIX.1 > * provision, and b) creates potential confusion with the former. Thus, we > * prefer to conform with POSIX.1 functional semantics, and recommend that > * users avoid the potentially confusing FD_SET typedefs, so allowing us > * to provide this function prototype: > */ > void FD_SET (SOCKET, fd_set *); > > #else /* _WINSOCK_ANOMALOUS_TYPEDEFS */ > /* However, for users who insist on eschewing standard C/C++ syntax, and > * for whatever reason must use FD_SET as a data type, instead of correctly > * referring to fd_set, or for pointer references, use PFD_SET or LPFD_SET > * instead of standard fd_set * references, we make these anomalous types > * visible, when the _WINSOCK_ANOMALOUS_TYPEDEFS feature test macro is > * defined with a non-zero value. > */ > #warning "FD_SET, PFD_SET, and LPFD_SET data types are non-portable." > #warning "Use portable fd_set, and fd_set * type references instead." > > typedef struct fd_set FD_SET, *PFD_SET, *LPFD_SET; > #endif > #define FD_SET( __fd, __set ) __FD_SET ((__fd), (__set)) > __CRT_ALIAS void __FD_SET (SOCKET __fd, fd_set *__set) > { if( (__set->fd_count < FD_SETSIZE) && ! FD_ISSET (__fd, __set) ) > __set->fd_array[__set->fd_count++] = __fd; > } > #endif /* ! defined FD_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: > > ####################### > APItest.o:APItest.c:(.text+0x5c83): undefined reference to `_imp__Perl_to_utf8_title' > APItest.o:APItest.c:(.text+0xb293): undefined reference to `_imp__Perl_to_utf8_upper' > APItest.o:APItest.c:(.text+0xb9e3): undefined reference to `_imp__Perl_to_utf8_fold' > APItest.o:APItest.c:(.text+0xc2d3): undefined reference to `_imp__Perl_to_utf8_lower' > collect2.exe: erreur: ld a retourné 1 code d'état d'exécution > Makefile:483: recipe for target '..\..\lib\auto\XS\APItest\APItest.dll' failed > gmake[1]: *** [..\..\lib\auto\XS\APItest\APItest.dll] Error 1 > gmake[1]: Leaving directory 'C:/_32/mingw32_new_comp/perl-5.27.11/ext/XS-APItest > ' > Unsuccessful make(ext/XS-APItest): code=512 at ..\make_ext.pl line 570. > GNUmakefile:1578: recipe for target 'Extensions' failed > make: *** [Extensions] Error 2 > ####################### > > At that point it became a case of either throwing a brick through the console, or walking away. > Wisely, I decided to walk away. Perhaps I can return to it later. > > Back last century, I was a big fan of mingw.org's work. > But, these days, I find it not in the least surprising that they're being deserted in favour of the mingw-w64 compilers. >
I didn't realize things were so bad in the new (v5.3.0 and v6.3.0) versions. I thought the project had died after v4.8.1 actually. I'm slightly wishing it had done now! Even v4.8.1 doesn't work overly well - I also see warnings (not errors) about the FD_SET thing, though the build does at least work. (But not in C++ mode, where those warnings become errors...) I think I will let this go since it's looking like more trouble than it's worth. But I will update documentation to reflect the fact that we only now have support for MinGW v3 and v4. (We currently claim to support v3.4.5 or higher.) Similar problems were also reported in [perl #133041] for v6.3.0. I will merge the two tickets if I can figure out how to do that.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 347b
Thanks 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.
Date: Thu, 24 May 2018 13:39:40 +0100
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
CC: perl5-porters [...] perl.org
Subject: Re: [perl #128631] Win32 MinGW build failure
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 4.8k
On 14 May 2018 at 14:07, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text
> On 11 May 2018 at 14:56, sisyphus@cpan.org via RT > <perlbug-followup@perl.org> wrote:
>> On Thu, 10 May 2018 05:58:06 -0700, shay wrote: >>
>>> I've only just discovered that new mingw.org compilers (v5 and v6) >>> even exist.
>> >> Ignoring my better judgement, I installed mingw.org's 6.3.0 compiler and tried to build perl-5.27.11. >> However, after working around the problem involving mkstemp (which is easy enough, for some definition of "easy enough"), I then get hammered with: >> >> win32sck.c: In function 'win32_select': >> win32sck.c:494:12: erreur: expected ';' before 'nrd' >> FD_SET nrd, nwr, nex; >> >> When I take a look at the pertinent winsock.h, I find the following pedantic drivel: >> >> /********************************/ >> #ifndef FD_SET >> #if !_WINSOCK_ANOMALOUS_TYPEDEFS >> /* WinSock is intended to mimic the Berkeley Sockets API, for which >> * POSIX.1 provides a reference specification; this states that FD_SET >> * may be implemented as either a macro, or as a function. The reference >> * <winsock.h> implementation at http://www.sockets.com/winsock.htm#WinsockH >> * includes a typedef for FD_SET, which a) conflicts with the latter POSIX.1 >> * provision, and b) creates potential confusion with the former. Thus, we >> * prefer to conform with POSIX.1 functional semantics, and recommend that >> * users avoid the potentially confusing FD_SET typedefs, so allowing us >> * to provide this function prototype: >> */ >> void FD_SET (SOCKET, fd_set *); >> >> #else /* _WINSOCK_ANOMALOUS_TYPEDEFS */ >> /* However, for users who insist on eschewing standard C/C++ syntax, and >> * for whatever reason must use FD_SET as a data type, instead of correctly >> * referring to fd_set, or for pointer references, use PFD_SET or LPFD_SET >> * instead of standard fd_set * references, we make these anomalous types >> * visible, when the _WINSOCK_ANOMALOUS_TYPEDEFS feature test macro is >> * defined with a non-zero value. >> */ >> #warning "FD_SET, PFD_SET, and LPFD_SET data types are non-portable." >> #warning "Use portable fd_set, and fd_set * type references instead." >> >> typedef struct fd_set FD_SET, *PFD_SET, *LPFD_SET; >> #endif >> #define FD_SET( __fd, __set ) __FD_SET ((__fd), (__set)) >> __CRT_ALIAS void __FD_SET (SOCKET __fd, fd_set *__set) >> { if( (__set->fd_count < FD_SETSIZE) && ! FD_ISSET (__fd, __set) ) >> __set->fd_array[__set->fd_count++] = __fd; >> } >> #endif /* ! defined FD_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: >> >> ####################### >> APItest.o:APItest.c:(.text+0x5c83): undefined reference to `_imp__Perl_to_utf8_title' >> APItest.o:APItest.c:(.text+0xb293): undefined reference to `_imp__Perl_to_utf8_upper' >> APItest.o:APItest.c:(.text+0xb9e3): undefined reference to `_imp__Perl_to_utf8_fold' >> APItest.o:APItest.c:(.text+0xc2d3): undefined reference to `_imp__Perl_to_utf8_lower' >> collect2.exe: erreur: ld a retourné 1 code d'état d'exécution >> Makefile:483: recipe for target '..\..\lib\auto\XS\APItest\APItest.dll' failed >> gmake[1]: *** [..\..\lib\auto\XS\APItest\APItest.dll] Error 1 >> gmake[1]: Leaving directory 'C:/_32/mingw32_new_comp/perl-5.27.11/ext/XS-APItest >> ' >> Unsuccessful make(ext/XS-APItest): code=512 at ..\make_ext.pl line 570. >> GNUmakefile:1578: recipe for target 'Extensions' failed >> make: *** [Extensions] Error 2 >> ####################### >> >> At that point it became a case of either throwing a brick through the console, or walking away. >> Wisely, I decided to walk away. Perhaps I can return to it later. >> >> Back last century, I was a big fan of mingw.org's work. >> But, these days, I find it not in the least surprising that they're being deserted in favour of the mingw-w64 compilers. >>
> > I didn't realize things were so bad in the new (v5.3.0 and v6.3.0) > versions. I thought the project had died after v4.8.1 actually. I'm > slightly wishing it had done now! > > Even v4.8.1 doesn't work overly well - I also see warnings (not > errors) about the FD_SET thing, though the build does at least work. > (But not in C++ mode, where those warnings become errors...) > > I think I will let this go since it's looking like more trouble than > it's worth. But I will update documentation to reflect the fact that > we only now have support for MinGW v3 and v4. (We currently claim to > support v3.4.5 or higher.) > > Similar problems were also reported in [perl #133041] for v6.3.0. I > will merge the two tickets if I can figure out how to do that.
I've now updated the documentation, in commit 8a217c9aa73da6153273a3bfa4c89fa15e95587b.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org