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

Win32 MinGW build failure #15446

Closed
p5pRT opened this issue Jul 16, 2016 · 22 comments
Closed

Win32 MinGW build failure #15446

p5pRT opened this issue Jul 16, 2016 · 22 comments
Labels
Closable? distro-mswin32 MinGW.org Portability

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Jul 16, 2016

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

Searchable as RT128631$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jul 16, 2016

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
Copy link
Author

@p5pRT p5pRT commented Jul 16, 2016

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
Copy link
Author

@p5pRT p5pRT commented Jul 16, 2016

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
Copy link
Author

@p5pRT p5pRT commented Jul 16, 2016

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jul 16, 2016

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
Copy link
Author

@p5pRT p5pRT commented Jul 16, 2016

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
Copy link
Author

@p5pRT p5pRT commented Jul 16, 2016

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
Copy link
Author

@p5pRT p5pRT commented Jul 16, 2016

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
Copy link
Author

@p5pRT p5pRT commented Jul 16, 2016

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
Copy link
Author

@p5pRT p5pRT commented Jul 16, 2016

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
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

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
Copy link
Author

@p5pRT p5pRT commented May 10, 2018

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

This comment has been minimized.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 11, 2018

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
Copy link
Author

@p5pRT p5pRT commented May 11, 2018

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 11, 2018

From @bulk88

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 14, 2018

From @steve-m-hay

On 11 May 2018 at 14​:56, sisyphus@​cpan.org via RT
<perlbug-followup@​perl.org> wrote​:

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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 14, 2018

From @steve-m-hay

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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 14, 2018

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 24, 2018

From @steve-m-hay

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

@toddr
Copy link
Member

@toddr toddr commented Feb 13, 2020

@steve-m-hay I think documentation is all that can be done in this case, right?

@toddr toddr added the Closable? label Feb 13, 2020
@toddr toddr added the MinGW.org Portability label Feb 14, 2020
@steve-m-hay
Copy link
Contributor

@steve-m-hay steve-m-hay commented Jan 26, 2021

Thanks for the report and suggested fixes.
I'm now closing this issue since the original mkstemp() problem should now be fixed by commit 341a561.
For the remaining win32sck.c problem (and another win32.c problem!) I have raised #18510.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closable? distro-mswin32 MinGW.org Portability
Projects
None yet
Development

No branches or pull requests

3 participants