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

[PATCH] fix win32 with Ming.org GCC 3.4.5 build #16498

Closed
p5pRT opened this issue Apr 7, 2018 · 9 comments
Closed

[PATCH] fix win32 with Ming.org GCC 3.4.5 build #16498

p5pRT opened this issue Apr 7, 2018 · 9 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Apr 7, 2018

Migrated from rt.perl.org#133084 (status was 'resolved')

Searchable as RT133084$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 7, 2018

From @bulk88

Created by @bulk88

See attached patch. This is intended for 5.28. Maybe backport too.
Although not addressed in
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132860 some questions in the
last month on the P5P ML over what CCs exactly work vs what the README
says made me test very old GCCs.

Perl Info
---
Flags:
              category=core
              severity=low
---
Site configuration information for perl 5.27.9:

Configured by Administrator at Tue Jan 30 20:34:30 2018.

Summary of my perl5 (revision 5 version 27 subversion 9) configuration:

            Platform:
              osname=MSWin32
              osvers=5.2.3790
              archname=MSWin32-x86-multi-thread
              uname=''
              config_args='undef'
              hint=recommended
              useposix=true
              d_sigaction=undef
              useithreads=define
              usemultiplicity=define
              use64bitint=undef
              use64bitall=undef
              uselongdouble=undef
              usemymalloc=n
              default_inc_excludes_dot=define
              bincompat5005=undef
            Compiler:
              cc='cl'
              ccflags ='-nologo -GF -W3 -O1 -MD -Zi -DNDEBUG -GL -DWIN32
-D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE
-D_CRT_NONSTDC_NO_DEPRECATE  -DPERL_TEXTMODE_SCRIPTS
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DWIN32_NO_REGISTRY'
              optimize='-O1 -MD -Zi -DNDEBUG -GL'
              cppflags='-DWIN32'
              ccversion='15.00.30729.01'
              gccversion=''
              gccosandvers=''
              intsize=4
              longsize=4
              ptrsize=4
              doublesize=8
              byteorder=1234
              doublekind=3
              d_longlong=undef
              longlongsize=8
              d_longdbl=define
              longdblsize=8
              longdblkind=0
              ivtype='long'
              ivsize=4
              nvtype='double'
              nvsize=8
              Off_t='__int64'
              lseeksize=8
              alignbytes=8
              prototype=define
            Linker and Libraries:
              ld='link'
              ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -ltcg
-libpath:"c:\perl\lib\CORE"        -machine:x86'
              libpth="C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\lib"
              libs=oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib
odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib
              perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib
odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib
              libc=msvcrt.lib
              so=dll
              useshrplib=true
              libperl=perl527.lib
              gnulibc_version=''
            Dynamic Linking:
              dlsrc=dl_win32.xs
              dlext=dll
              d_dlsymun=undef
              ccdlflags=' '
              cccdlflags=' '
              lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf 
-ltcg
              -libpath:"c:\perl\lib\CORE"        -machine:x86'


---
@INC for perl 5.27.9:
              lib
              C:/p527/srcnew/lib

---
Environment for perl 5.27.9:
              CYGWIN=tty
              HOME (unset)
              LANG (unset)
              LANGUAGE (unset)
              LD_LIBRARY_PATH=/usr/lib/x86:/usr/X11R6/lib
              LOGDIR (unset)
              PATH=C:\WINDOWS\system32;C:\Program Files (x86)\Microsoft
Visual
Studio 9.0\VC\BIN;C:\Program Files\Microsoft
SDKs\Windows\v6.0A\bin;C:\Perl\bin;C:\WINDOWS;C:\Program Files
(x86)\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program Files
(x86)\Git\bin;C:\sp3220\c\bin;
              PERL_BADLANG (unset)
              SHELL (unset)


@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 7, 2018

From @bulk88

0001-fix-win32-with-Ming.org-GCC-3.4.5-build.patch
From d29cee8acac409d714598b1e81c3494b22a16e30 Mon Sep 17 00:00:00 2001
From: Daniel Dragan <bulk88@hotmail.com>
Date: Fri, 6 Apr 2018 18:41:22 -0400
Subject: [PATCH] fix win32 with Ming.org GCC 3.4.5 build

dlltool 2.20.51.20100123 from Strawberry 5.12 and
dlltool 2.17.50 20060824 from Strawberry 5.8.9 were making a libperl527.a
that caused perl.exe and all XS DLLs to import "perl527.exp.dll" while
the disk file is called perl527.dll.

This bug was eventually fixed, since in my testing dlltool 2.25 no date
code, Copyright 2014 from Strawberry 5.22.1 doesn't have this problem. I
suspect the bug was fixed in binutils commit 04276a0cf5
"2010-12-01 Kai Tietz <kai.tietz@onevision.com>"
https://sourceware.org/bugzilla/show_bug.cgi?id=11065
in version "AM_INIT_AUTOMAKE(bfd, 2.21.51)" or 1 ver bump higher. Just
always pass an explicit DLL name to dlltool instead of any kind of
dlltool version checking at build time and then optional arg.

The breakage for Mingw.org 3.4.5 was introduced in
commit bf543eaf90d "add parallelness to win32/GNUmakefile" where I added
parallelness by making the import lib .a file from just perldll.def,
rather than the import lib being a build product coming out of g++
linking perl527.dll. The old serial build recipie passed --dllname
to dlltool, my newer code didn't.

Passing $(PERLDLL) to dlltool's -D causes this harmless but scary warning

"dlltool: Path components stripped from dllname, '..\perl527.dll'."

So create PERLDLLBASE to silence the warning.

win32.h: In old GCCs,
https://sourceforge.net/p/mingw/mailman/message/22184185/ a function marked
declspec(dllimport) is not a constant. VC from day 1, and newer GCCs use
the address of a 1 instruction jump stub function if a constant function
pointer is needed to a function from a DLL that wont be known till runtime.
This can be worked around in older GCCs by deoptimizing them to always
use the jump stub for all references, and not the newer GCC and VC way
where x86 call instructions directly read the import table in the caller,
while constant functions ptrs in data or vars always refer to the jump
stubs. Since these are old GCCs, performance isn't the highest priority
and building at all is a more important goal. I suspect gcc 3.4.5 has
been broken since 5.13.6 when the declspec(dllimport) code was added.
---
 win32/GNUmakefile |  3 ++-
 win32/makefile.mk |  3 ++-
 win32/win32.h     | 43 +++++++++++++++++++++++++++++++------------
 3 files changed, 35 insertions(+), 14 deletions(-)

diff --git a/win32/GNUmakefile b/win32/GNUmakefile
index ac4632b..82bf593 100644
--- a/win32/GNUmakefile
+++ b/win32/GNUmakefile
@@ -963,6 +963,7 @@ PERLIMPLIBBASE	?= perl527$(a)
 PERLEXPLIB	?= $(COREDIR)\perl527.exp
 PERLSTATICLIB	?= ..\perl527s$(a)
 PERLDLL		= ..\perl527.dll
+PERLDLLBASE	= perl527.dll
 
 # don't let "gmake -n all" try to run "miniperl.exe make_ext.pl"
 PLMAKE		= gmake
@@ -1478,7 +1479,7 @@ $(PERLEXPLIB) : $(PERLIMPLIB)
 
 $(PERLIMPLIB) : perldll.def
 ifeq ($(CCTYPE),GCC)
-	$(IMPLIB) -k -d perldll.def -l $(PERLIMPLIB) -e $(PERLEXPLIB)
+	$(IMPLIB) -k -d perldll.def -D $(PERLDLLBASE) -l $(PERLIMPLIB) -e $(PERLEXPLIB)
 else
 	lib -def:perldll.def -machine:$(ARCHITECTURE) /OUT:$(PERLIMPLIB)
 endif
diff --git a/win32/makefile.mk b/win32/makefile.mk
index 57563c4..265e93b 100644
--- a/win32/makefile.mk
+++ b/win32/makefile.mk
@@ -937,6 +937,7 @@ PERLIMPLIB	*= $(COREDIR)\perl527$(a)
 PERLEXPLIB	*= $(COREDIR)\perl527.exp
 PERLSTATICLIB	*= ..\perl527s$(a)
 PERLDLL		= ..\perl527.dll
+PERLDLLBASE	= perl527.dll
 
 #EUMM on Win32 isn't ready for parallel make, so only allow this file to be parallel
 #$(MAKE) will contain the -P that this makefile was called with, which is bad for
@@ -1427,7 +1428,7 @@ perldll.def : $(HAVEMINIPERL) $(CONFIGPM) ..\embed.fnc ..\makedef.pl
 
 $(PERLEXPLIB) $(PERLIMPLIB) .UPDATEALL : perldll.def
 .IF "$(CCTYPE)" == "GCC"
-	$(IMPLIB) -k -d perldll.def -l $(PERLIMPLIB) -e $(PERLEXPLIB)
+	$(IMPLIB) -k -d perldll.def -D $(PERLDLLBASE) -l $(PERLIMPLIB) -e $(PERLEXPLIB)
 .ELSE #VC family
 	lib -def:perldll.def -machine:$(ARCHITECTURE) /OUT:$(PERLIMPLIB)
 .ENDIF
diff --git a/win32/win32.h b/win32/win32.h
index c3fbe9b..1f05a27 100644
--- a/win32/win32.h
+++ b/win32/win32.h
@@ -103,23 +103,42 @@
  * The XS code in the re extension is special, in that it redefines
  * core APIs locally, so don't mark them as "dllimport" because GCC
  * cannot handle this situation.
+ *
+ * Certain old GCCs will not allow the function pointer of dllimport marked
+ * function to be "const". This was fixed later on. Since this is a
+ * deoptimization, target "gcc version 3.4.5 (mingw-vista special r3)" only,
+ * The GCC bug was fixed in GCC patch "varasm.c (initializer_constant_valid_p):
+ * Don't deny DECL_DLLIMPORT_P on functions", which probably was first released
+ * in GCC 4.3.0, this #if can be expanded upto but not including 4.3.0 if more
+ * deployed GCC are found that wont build with the follow error, initializer
+ * element is a PerlIO func exported from perl5xx.dll.
+ *
+ * encoding.xs:610: error: initializer element is not constant
+ * encoding.xs:610: error: (near initialization for `PerlIO_encode.Open')
  */
-#if !defined(PERLDLL) && !defined(PERL_EXT_RE_BUILD)
-#  ifdef __cplusplus
-#    define PERL_CALLCONV extern "C" __declspec(dllimport)
-#    ifdef _MSC_VER
-#      define PERL_CALLCONV_NO_RET extern "C" __declspec(dllimport) __declspec(noreturn)
+
+#if (defined(__GNUC__) && defined(__MINGW32__) && \
+     !defined(__MINGW64_VERSION_MAJOR) && !defined(__clang__) && \
+	((__GNUC__ < 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ <= 5))))
+/* use default fallbacks from perl.h for this particular GCC */
+#else
+#  if !defined(PERLDLL) && !defined(PERL_EXT_RE_BUILD)
+#    ifdef __cplusplus
+#      define PERL_CALLCONV extern "C" __declspec(dllimport)
+#      ifdef _MSC_VER
+#        define PERL_CALLCONV_NO_RET extern "C" __declspec(dllimport) __declspec(noreturn)
+#      endif
+#    else
+#      define PERL_CALLCONV __declspec(dllimport)
+#      ifdef _MSC_VER
+#        define PERL_CALLCONV_NO_RET __declspec(dllimport) __declspec(noreturn)
+#      endif
 #    endif
-#  else
-#    define PERL_CALLCONV __declspec(dllimport)
+#  else /* MSVC noreturn support inside the interp */
 #    ifdef _MSC_VER
-#      define PERL_CALLCONV_NO_RET __declspec(dllimport) __declspec(noreturn)
+#      define PERL_CALLCONV_NO_RET __declspec(noreturn)
 #    endif
 #  endif
-#else /* MSVC noreturn support inside the interp */
-#  ifdef _MSC_VER
-#    define PERL_CALLCONV_NO_RET __declspec(noreturn)
-#  endif
 #endif
 
 #ifdef _MSC_VER
-- 
2.5.0.windows.1

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 11, 2018

From @steve-m-hay

On Sat, 07 Apr 2018 15​:45​:42 -0700, bulk88 wrote​:

This is a bug report for perl from bulk88@​hotmail.com,
generated with the help of perlbug 1.41 running under perl 5.27.9.

-----------------------------------------------------------------
[Please describe your issue here]

See attached patch. This is intended for 5.28. Maybe backport too.
Although not addressed in
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132860 some questions in the
last month on the P5P ML over what CCs exactly work vs what the README
says made me test very old GCCs.

Thanks for the patch (and for spotting the breakage - I hadn't built with gcc 3.4.5 for quite a while).

I can confirm that without the patch blead currently doesn't build, and with the patch all is well. But I have two test failures from that build. Do you see this too?

ext/XS-APItest/t/call_checker.t - fails one test
ext/XS-APItest/t/win32.t - passes all tests but crashes on exit

C​:\Dev\Git\perl\t>.\perl harness -v ../ext/XS-APItest/t/call_checker.t
../ext/XS-APItest/t/call_checker.t ..
1..78
not ok 1# Failed (TODO) test at t/call_checker.t line 9.

# fail 67ac4520!=6478b0d8 at APItest.xs line 3210 at t/call_checker.t line 9.
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
ok 14
ok 15
ok 16
ok 17
ok 18
ok 19
ok 20
ok 21
ok 22
ok 23
ok 24
ok 25# Looks like you failed 1 test of 78.

ok 26
ok 27
ok 28
ok 29
ok 30
ok 31
ok 32
ok 33
ok 34
ok 35
ok 36
ok 37
ok 38
ok 39
ok 40
ok 41
ok 42
ok 43
ok 44
ok 45
ok 46
ok 47
ok 48
ok 49
ok 50
ok 51
ok 52
ok 53
ok 54
ok 55
ok 56
ok 57
ok 58
ok 59
ok 60
ok 61
ok 62
ok 63
ok 64
ok 65
ok 66
ok 67
ok 68
ok 69
ok 70
ok 71 - undef clears call checkers
ok 72
ok 73
ok 74
ok 75
ok 76
ok 77
ok 78
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/78 subtests

Test Summary Report


../ext/XS-APItest/t/call_checker.t (Wstat​: 256 Tests​: 78 Failed​: 1)
  Failed test​: 1
  Non-zero exit status​: 1
Files=1, Tests=78, 0 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU)
Result​: FAIL

C​:\Dev\Git\perl\t>.\perl harness -v ../ext/XS-APItest/t/win32.t
../ext/XS-APItest/t/win32.t ..
ok 1 - check good drive A
ok 2 - check a good drive (wide)
ok 3 - check good drive B
ok 4 - check a good drive (wide)
ok 5 - check good drive C
ok 6 - check a good drive (wide)
ok 7 - check good drive D
ok 8 - check a good drive (wide)
ok 9 - check good drive E
ok 10 - check a good drive (wide)
ok 11 - check good drive F
ok 12 - check a good drive (wide)
ok 13 - check good drive G
ok 14 - check a good drive (wide)
ok 15 - check good drive H
ok 16 - check a good drive (wide)
ok 17 - check good drive I
ok 18 - check a good drive (wide)
ok 19 - check good drive J
ok 20 - check a good drive (wide)
ok 21 - check good drive K
ok 22 - check a good drive (wide)
ok 23 - check good drive L
ok 24 - check a good drive (wide)
ok 25 - check good drive M
ok 26 - check a good drive (wide)
ok 27 - check good drive N
ok 28 - check a good drive (wide)
ok 29 - check good drive O
ok 30 - check a good drive (wide)
ok 31 - check good drive P
ok 32 - check a good drive (wide)
ok 33 - check good drive Q
ok 34 - check a good drive (wide)
ok 35 - check good drive R
ok 36 - check a good drive (wide)
ok 37 - check good drive S
ok 38 - check a good drive (wide)
ok 39 - check good drive T
ok 40 - check a good drive (wide)
ok 41 - check good drive U
ok 42 - check a good drive (wide)
ok 43 - check good drive V
ok 44 - check a good drive (wide)
ok 45 - check good drive W
ok 46 - check a good drive (wide)
ok 47 - check good drive X
ok 48 - check a good drive (wide)
ok 49 - check good drive Y
ok 50 - check a good drive (wide)
ok 51 - check good drive Z
ok 52 - check a good drive (wide)
ok 53 - check good drive a
ok 54 - check a good drive (wide)
ok 55 - check good drive b
ok 56 - check a good drive (wide)
ok 57 - check good drive c
ok 58 - check a good drive (wide)
ok 59 - check good drive d
ok 60 - check a good drive (wide)
ok 61 - check good drive e
ok 62 - check a good drive (wide)
ok 63 - check good drive f
ok 64 - check a good drive (wide)
ok 65 - check good drive g
ok 66 - check a good drive (wide)
ok 67 - check good drive h
ok 68 - check a good drive (wide)
ok 69 - check good drive i
ok 70 - check a good drive (wide)
ok 71 - check good drive j
ok 72 - check a good drive (wide)
ok 73 - check good drive k
ok 74 - check a good drive (wide)
ok 75 - check good drive l
ok 76 - check a good drive (wide)
ok 77 - check good drive m
ok 78 - check a good drive (wide)
ok 79 - check good drive n
ok 80 - check a good drive (wide)
ok 81 - check good drive o
ok 82 - check a good drive (wide)
ok 83 - check good drive p
ok 84 - check a good drive (wide)
ok 85 - check good drive q
ok 86 - check a good drive (wide)
ok 87 - check good drive r
ok 88 - check a good drive (wide)
ok 89 - check good drive s
ok 90 - check a good drive (wide)
ok 91 - check good drive t
ok 92 - check a good drive (wide)
ok 93 - check good drive u
ok 94 - check a good drive (wide)
ok 95 - check good drive v
ok 96 - check a good drive (wide)
ok 97 - check good drive w
ok 98 - check a good drive (wide)
ok 99 - check good drive x
ok 100 - check a good drive (wide)
ok 101 - check good drive y
ok 102 - check a good drive (wide)
ok 103 - check good drive z
ok 104 - check a good drive (wide)
ok 105 - check bad drive @​​:
ok 106 - check bad drive @​​: (wide)
ok 107 - check bad drive [​:
ok 108 - check bad drive [​: (wide)
ok 109 - check bad drive !​:
ok 110 - check bad drive !​: (wide)
ok 111 - check bad drive ~​:
ok 112 - check bad drive ~​: (wide)
ok 113 - check bad drive `​:
ok 114 - check bad drive `​: (wide)
ok 115 - check bad drive {​:
ok 116 - check bad drive {​: (wide)
Dubious, test returned 5 (wstat 1280, 0x500)
All 116 subtests passed

Test Summary Report


../ext/XS-APItest/t/win32.t (Wstat​: 1280 Tests​: 116 Failed​: 0)
  Non-zero exit status​: 5
  Parse errors​: No plan found in TAP output
Files=1, Tests=116, 2 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU)
Result​: FAIL

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 11, 2018

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 11, 2018

From @bulk88

On Wed, 11 Apr 2018 05​:27​:39 -0700, shay wrote​:

Thanks for the patch (and for spotting the breakage - I hadn't built
with gcc 3.4.5 for quite a while).

I can confirm that without the patch blead currently doesn't build,
and with the patch all is well. But I have two test failures from that
build. Do you see this too?

ext/XS-APItest/t/call_checker.t - fails one test
ext/XS-APItest/t/win32.t - passes all tests but crashes on exit

C​:\Dev\Git\perl\t>.\perl harness -v ../ext/XS-APItest/t/call_checker.t
../ext/XS-APItest/t/call_checker.t ..
1..78
not ok 1# Failed (TODO) test at t/call_checker.t line 9.

# fail 67ac4520!=6478b0d8 at APItest.xs line 3210 at t/call_checker.t
line 9.

Known problem, https​://rt.perl.org/Ticket/Display.html?id=78502 https://perl5.git.perl.org/perl.git/commitdiff/ad6ab6c50 the declspec(dllimport) was added specifically 3 weeks after call_checker.t was commited. So the same symbol name func ptrs being != between libperl.dll and XS DLLs has always been there. I can imagine subtle bugs with XS libraries that patch function pointers in core and want to know if its the original p5p supplied func ptr in the var or a unk 3rd party func ptr or their own func ptr. You can't detect if its a p5p func ptr or not anymore. But I'd say for patch/hook chains, dont devs save the old func ptr, put in their own func ptr, then call the old func ptr from the body of their new func, not caring if the old func ptr is original to p5p or yet another hook?

On old Mingws, either use declspec(dllimport) and get the same func ptrs, but then you can't use those symbols in a const/static global data (a PerlIO vtable), or dont use declspec(dllimport) but now you can create const global data in a XS DLL with symbols from libperl.dll . I tried removing the "const" from the perlio vtable by commenting out #define PERLIO_FUNCS_CONST in perl.h, still got the const initializer warning.


static PerlIO_funcs PerlIO_encode = {
  sizeof(PerlIO_funcs),
  "encoding",
  sizeof(PerlIOEncode),
  0x00000002|0x00010000,
  PerlIOEncode_pushed,
  PerlIOEncode_popped,
  PerlIOBuf_open,
  ((void *)0),
  PerlIOEncode_getarg,
  PerlIOBase_fileno,
  PerlIOEncode_dup,
  PerlIOBuf_read,
  PerlIOBuf_unread,
  PerlIOEncode_write,
  PerlIOBuf_seek,
  PerlIOEncode_tell,
  PerlIOEncode_close,
  PerlIOEncode_flush,
  PerlIOEncode_fill,
  PerlIOBase_eof,
  PerlIOBase_error,
  PerlIOBase_clearerr,
  PerlIOBase_setlinebuf,
  PerlIOEncode_get_base,
  PerlIOBuf_bufsiz,
  PerlIOBuf_get_ptr,
  PerlIOBuf_get_cnt,
  PerlIOBuf_set_ptrcnt,
};


I also tried to move that var into the boot XSUB, again const init error, until I removed "static" which made it a C auto scoped to the boot XSUB and it stopped erroring.

Putting this in the boot XSUB also works.

  PerlIO_encode.fsize = sizeof(PerlIO_funcs);
  PerlIO_encode.name = "encoding";
  PerlIO_encode.size = sizeof(PerlIOEncode);
  PerlIO_encode.kind = PERLIO_K_BUFFERED|PERLIO_K_DESTRUCT;
  PerlIO_encode.Pushed = PerlIOEncode_pushed;
  PerlIO_encode.Popped = PerlIOEncode_popped;
  PerlIO_encode.Open = PerlIOBuf_open;
etc

Commit https://perl5.git.perl.org/perl.git/commitdiff/ad6ab6c50 did break Mingw 3.4.5 like this


Running Makefile.PL in ext/Win32CORE
C​:\perl521\srcnew\win32\..\miniperl.exe Makefile.PL INSTALLDIRS=perl INSTALLMAN1
DIR=none INSTALLMAN3DIR=none PERL_CORE=1 LINKTYPE=static
Writing Makefile for Win32CORE
Writing MYMETA.yml
Making all in ext/Win32CORE
b88dmake -S all PERL_CORE=1 LINKTYPE=static
cp Win32CORE.pm ..\..\lib\Win32CORE.pm
gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_
IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -DPERL_MSVCRT_READFIX -DPERLDLL
-UUSEIMPORTLIB -s -O2 -DVERSION=\"0.02\" -DXS_VERSION=\"0.02\" "-I..\..\
lib\CORE" Win32CORE.c
C​:\perl521\srcnew\miniperl.exe "-I..\..\lib" "-I..\..\lib" -MExtUtils​::Command -
e "rm_rf" -- ..\..\lib\auto\Win32CORE\Win32CORE.a
ar -ru ..\..\lib\auto\Win32CORE\Win32CORE.a Win32CORE.o
ar​: creating ..\..\lib\auto\Win32CORE\Win32CORE.a
C​:\perl521\srcnew\miniperl.exe "-I..\..\lib" "-I..\..\lib" -MExtUtils​::Command -
e "chmod" -- 755 ..\..\lib\auto\Win32CORE\Win32CORE.a
..\miniperl.exe -I..\lib list_static_libs.pl > Extensions_static
g++ -mdll -o ..\perl513.dll -Wl,--base-file -Wl,perl.base -s -L"c​:\perl\lib\COR
E" -L"C​:\MinGW\lib" \
  C​:\WINDOWS\TEMP\mk7036_2030_4
..\DynaLoader.o​:DynaLoader.c​:(.text+0x32)​: undefined reference to `_imp__Perl_vm
ess'
..\DynaLoader.o​:DynaLoader.c​:(.text+0x60)​: undefined reference to `_imp__Perl_sv
_setpvn'
..\DynaLoader.o​:DynaLoader.c​:(.text+0x89)​: undefined reference to `_imp__Perl_sv
_2pv_flags'
..\DynaLoader.o​:DynaLoader.c​:(.text+0xa9)​: undefined reference to `_imp__Perl_sv
_setpvn'
..\DynaLoader.o​:DynaLoader.c​:(.text+0x13c)​: undefined reference to `_imp__Perl_n
ewSVpvn'
..\DynaLoader.o​:DynaLoader.c​:(.text+0x18c)​: undefined reference to `_imp__Perl_s
v_2pv_flags'
..\DynaLoader.o​:DynaLoader.c​:(.text+0xaa3)​: undefined reference to `_imp__Perl_x
s_apiversion_bootcheck'
..\DynaLoader.o​:DynaLoader.c​:(.text+0xacb)​: undefined reference to `_imp__Perl_x
s_version_bootcheck'
..\DynaLoader.o​:DynaLoader.c​:(.text+0xaef)​: undefined reference to `_imp__Perl_n
ewXS'
..\DynaLoader.o​:DynaLoader.c​:(.text+0xb13)​: undefined reference to `_imp__Perl_n
ewXS'
..\DynaLoader.o​:DynaLoader.c​:(.text+0xb37)​: undefined reference to `_imp__Perl_n
ewXS'
..\DynaLoader.o​:DynaLoader.c​:(.text+0xb5b)​: undefined reference to `_imp__Perl_n
ewXS'
..\DynaLoader.o​:DynaLoader.c​:(.text+0xb7f)​: undefined reference to `_imp__Perl_n
ewXS'
..\DynaLoader.o​:DynaLoader.c​:(.text+0xb9e)​: more undefined references to `_imp__
Perl_newXS' follow
..\DynaLoader.o​:DynaLoader.c​:(.text+0xbdd)​: undefined reference to `_imp__Perl_m
y_cxt_init'
..\DynaLoader.o​:DynaLoader.c​:(.text+0xbf7)​: undefined reference to `_imp__Perl_n
ewSVpvn'
..\DynaLoader.o​:DynaLoader.c​:(.text+0xc60)​: undefined reference to `_imp__Perl_c
all_list'
..\lib\auto\Win32CORE\Win32CORE.a(Win32CORE.o)​:Win32CORE.c​:(.text+0xe)​: undefine
d reference to `_imp__Perl_get_context'
..\lib\auto\Win32CORE\Win32CORE.a(Win32CORE.o)​:Win32CORE.c​:(.text+0x16)​: undefin
ed reference to `_imp__Perl_get_context'
..\lib\auto\Win32CORE\Win32CORE.a(Win32CORE.o)​:Win32CORE.c​:(.text+0x27)​: undefin
ed reference to `_imp__Perl_get_context'
..\lib\auto\Win32CORE\Win32CORE.a(Win32CORE.o)​:Win32CORE.c​:(.text+0x45)​: undefin
ed reference to `_imp__Perl_get_context'
..\lib\auto\Win32CORE\Win32CORE.a(Win32CORE.o)​:Win32CORE.c​:(.text+0x58)​: undefin
..\lib\auto\Win32CORE\Win32CORE.a(Win32CORE.o)​:Win32CORE.c​:(.text+0x76a)​: undefi
ned reference to `_imp__Perl_newXS'
collect2​: ld returned 1 exit status
b88dmake​: Error code 129, while making '..\perl513.dll'

C​:\perl521\srcnew\win32>


This was fixed in https://perl5.git.perl.org/perl.git/50fd59617d035069f1af09e538c403b3e05768b3 and perl built sucessfully (other problems seem to exist at this point, Carp.pm syntax errors).

I tried more bisecting but I ran into build bugs I fixed 2014-2015 so not much builds around that era for me.

Test Summary Report
-------------------
../ext/XS-APItest/t/win32.t (Wstat​: 1280 Tests​: 116 Failed​: 0)
Non-zero exit status​: 5
Parse errors​: No plan found in TAP output
Files=1, Tests=116, 2 wallclock secs ( 0.02 usr + 0.00 sys = 0.02
CPU)
Result​: FAIL

If you comment out the last test in ../ext/XS-APItest/t/win32.t, the Comctl32Version() test does it still crash? I disable the comctrl DLL with a private patch so I get, note exit code "2", not your "5" which is a truncated 0xC0000005.

My run of the test


ok 95 - check good drive v
ok 96 - check a good drive (wide)
Comctl32Version​: comctl32.dll not in process??? at t/win32.t line 42.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 2 just after 116.
ok 97 - check good drive w
ok 98 - check a good drive (wide)
ok 99 - check good drive x
ok 100 - check a good drive (wide)
ok 101 - check good drive y
ok 102 - check a good drive (wide)
ok 103 - check good drive z
ok 104 - check a good drive (wide)
ok 105 - check bad drive @​​:
ok 106 - check bad drive @​​: (wide)
ok 107 - check bad drive [​:
ok 108 - check bad drive [​: (wide)
ok 109 - check bad drive !​:
ok 110 - check bad drive !​: (wide)
ok 111 - check bad drive ~​:
ok 112 - check bad drive ~​: (wide)
ok 113 - check bad drive `​:
ok 114 - check bad drive `​: (wide)
ok 115 - check bad drive {​:
ok 116 - check bad drive {​: (wide)
Dubious, test returned 2 (wstat 512, 0x200)
All 116 subtests passed

Test Summary Report


../ext/XS-APItest/t/win32.t (Wstat​: 512 Tests​: 116 Failed​: 0)
  Non-zero exit status​: 2
  Parse errors​: No plan found in TAP output
Files=1, Tests=116, 1 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU)
Result​: FAIL


--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 12, 2018

From @steve-m-hay

On 11 April 2018 at 17​:38, bulk88 via RT <perlbug-followup@​perl.org> wrote​:

On Wed, 11 Apr 2018 05​:27​:39 -0700, shay wrote​:

Test Summary Report
-------------------
../ext/XS-APItest/t/win32.t (Wstat​: 1280 Tests​: 116 Failed​: 0)
Non-zero exit status​: 5
Parse errors​: No plan found in TAP output
Files=1, Tests=116, 2 wallclock secs ( 0.02 usr + 0.00 sys = 0.02
CPU)
Result​: FAIL

If you comment out the last test in ../ext/XS-APItest/t/win32.t, the Comctl32Version() test does it still crash? I disable the comctrl DLL with a private patch so I get, note exit code "2", not your "5" which is a truncated 0xC0000005.

With the last test removed (specifically, with the Comctl32Version()
call removed) the crash goes away.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 12, 2018

From @steve-m-hay

Thanks again - the patch is now applied in blead commit 1b30b4a.

(I tried some later MinGW gccs (4.4.0, 4.5.0 and 4.8.1) and found the win32.h part was not necessary for them so I left the version check exactly as you had it.)

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 12, 2018

From [Unknown Contact. See original ticket]

Thanks again - the patch is now applied in blead commit 1b30b4a.

(I tried some later MinGW gccs (4.4.0, 4.5.0 and 4.8.1) and found the win32.h part was not necessary for them so I left the version check exactly as you had it.)

@p5pRT p5pRT closed this as completed Apr 12, 2018
@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 12, 2018

@steve-m-hay - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant