Win32 MinGW build failure

[p5pRT]

Migrated from rt.perl.org#128631 (status was 'open')

Searchable as RT128631$

[p5pRT]

From @dcollinsn

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

[p5pRT]

From @dcollinsn

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

[p5pRT]

From @sisyphus

-----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-archive.perl.org/perl5/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

[p5pRT]

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

[p5pRT]

From @dcollinsn

Current blead, commit 8bfa1b5. 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​:

-----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-archive.perl.org/perl5/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

[p5pRT]

From @sisyphus

From​: Dan Collins
Sent​: Saturday, July 16, 2016 12​:42 PM
To​: Perl RT Bug Tracker
Subject​: Re​: [perl #128631] Win32 MinGW build failure

Current blead, commit 8bfa1b5. 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.)

#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

[p5pRT]

From @sisyphus

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

[p5pRT]

From @dcollinsn

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

[p5pRT]

From @dcollinsn

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

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

[p5pRT]

From @sisyphus

From​: Dan Collins
Sent​: Saturday, July 16, 2016 2​:48 PM
To​: Perl RT Bug Tracker
Subject​: Re​: [perl #128631] Win32 MinGW build failure

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

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

[p5pRT]

From @dur-randir

Created by @dur-randir

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'

Perl Info

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)

[p5pRT]

From @steve-m-hay

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

[p5pRT]

From [Unknown Contact. See original ticket]

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?

[p5pRT]

From @sisyphus

On Thu, 10 May 2018 05​:58​:06 -0700, shay wrote​:

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.

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

[p5pRT]

From @sisyphus

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.

Cheers,
Rob