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

Owner: Nobody
Requestors: bulk88 <bulk88 [at] hotmail.com>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: core
Perl Version: 5.27.9
Fixed In: (no value)



Date: Thu, 8 Mar 2018 15:56:58 +0000
Subject: USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
From: bulk 88 <bulk88 [...] hotmail.com>
To: "perlbug [...] perl.org" <perlbug [...] perl.org>
Download (untitled) / with headers
text/plain 7.9k
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] 5.26 (maint-5.26) and 5.27 blead both fail with Win32 VC perl compiled with USE_CPLUSPLUS=define build option. Solution need backporting to 5.26. -------------------------------------- cl -c -nologo -GF -W3 -TP -EHsc -O1 -MD -Zi -DNDEBUG -GL -DWIN32 -D_CO NSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICI T_SYS -DWIN32_NO_REGISTRY -D_USE_32BIT_TIME_T -O1 -MD -Zi -DNDEBUG -GL -DVERS ION=\"1.76\" -DXS_VERSION=\"1.76\" "-I..\..\lib\CORE" POSIX.c POSIX.c "..\..\miniperl.exe" "-I..\..\lib" -MExtUtils::Mksymlists \ -e "Mksymlists('NAME'=>\"POSIX\", 'DLBASE' => 'POSIX', 'DL_FUNCS' => { }, 'FUNCLIST' => [], 'IMPORTS' => { }, 'DL_VARS' => []);" link -out:..\..\lib\auto\POSIX\POSIX.dll -dll -nologo -nodefaultlib -debug -opt: ref,icf -ltcg -libpath:"c:\perl\lib\CORE" -machine:x86 POS IX.obj "..\..\lib\CORE\perl526.lib" oldnames.lib kernel32.lib user32.lib gdi32 .lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib n etapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp3 2.lib comctl32.lib msvcrt.lib -def:POSIX.def Creating library ..\..\lib\auto\POSIX\POSIX.lib and object ..\..\lib\auto\POS IX\POSIX.exp POSIX.obj : error LNK2001: unresolved external symbol _PL_nan ..\..\lib\auto\POSIX\POSIX.dll : fatal error LNK1120: 1 unresolved externals dmake: Error code 224, while making '..\..\lib\auto\POSIX\POSIX.dll' --------------------------------------------- I traced the failure to https://perl5.git.perl.org/perl.git/commitdiff/0879cd66ef3f00918ae26d9bb7ac555d3911c548 plain C (works) vs C++ (broken) POSIX.i diff --------------------------------------------- --- C:\perl521\src\ext\POSIX\POSIX.c.i +++ C:\perl521\src\ext\POSIX\POSIX.p.i @@ -250844,8 +250844,8 @@ -extern __declspec(dllimport) const union { NV nv; U8 u8[8]; } PL_inf; -extern __declspec(dllimport) const union { NV nv; U8 u8[8]; } PL_nan; +extern "C" const union { NV nv; U8 u8[8]; } PL_inf; +extern "C" const union { NV nv; U8 u8[8]; } PL_nan; #line 6766 "..\\..\\lib\\CORE\\perl.h" --------------------------------------------- orig code --------------------------------------------- 5720 /* In C99 we could use designated (named field) union initializers. 5721 * In C89 we need to initialize the member declared first. 5722 * In C++ we need extern C initializers. 5723 * 5724 * With the U8_NV version you will want to have inner braces, 5725 * while with the NV_U8 use just the NV. */ 5726 5727 #ifdef __cplusplus 5728 #define INFNAN_U8_NV_DECL EXTERN_C const union { U8 u8[NVSIZE]; NV nv; } 5729 #define INFNAN_NV_U8_DECL EXTERN_C const union { NV nv; U8 u8[NVSIZE]; } 5730 #else 5731 #define INFNAN_U8_NV_DECL EXTCONST union { U8 u8[NVSIZE]; NV nv; } 5732 #define INFNAN_NV_U8_DECL EXTCONST union { NV nv; U8 u8[NVSIZE]; } 5733 #endif ------------------------------------------- So the var isn't declared as crossing DLL boundaries. So it doesnt, and therefore the Windows POSIX.xs wont link. EXTERN_C vs EXTCONST. https://perl5.git.perl.org/perl.git/commitdiff/0879cd66ef3f00918ae26d9bb7ac555d3911c548 that commit didnt explain why exactly by its author the exact linker problem in the first place he was having or what the error coming out of the CC/LD was. Reverting that commit fixes the Win32 C++ perl build. The 5.26 Win32 binary (perl526.dll) DOES export PL_nan and PL_inf symbols. It is a header problem. A 2nd less correct way of fixing it, is eliminating the use of global PL_nan on Win32 and using platform specific constant I put in win32.h a long time ago. --------------------------------- extern const __declspec(selectany) union { unsigned __int64 __q; double __d; } __PL_nan_u = { 0x7FF8000000000000UI64 }; #define NV_NAN ((NV)__PL_nan_u.__d) --------------------------------- A secondary reason why POSIX.xs fails is this macro https://perl5.git.perl.org/perl.git/blob/ecad93809368755639b71856840a4d6e6d599ade:/perl.h#l6960 6960 #define NV_NAN_QS_QUIET \ 6961 ((NV_NAN_QS_BYTE(PL_nan.u8) & NV_NAN_QS_BIT) == NV_NAN_QS_BIT) which uses PL_nan directly without the "platform specific" NV_NAN constant/maybe-not-a-constant identifier. But NV_NAN_QS_QUIET is from 5.23.0, much older than 5.26. It was the declaration of PL_nan that broke things in 5.26, not the accidental use of the not platform specific NAN PL_nan. [Please do not change anything below this line] ----------------------------------------------------------------- --- 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)
Date: Fri, 13 Apr 2018 09:20:39 +0100
From: Steve Hay <steve.m.hay [...] googlemail.com>
CC: bugs-bitbucket [...] rt.perl.org
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 3.7k
On 8 March 2018 at 15:57, bulk88 <perlbug-followup@perl.org> wrote: Show quoted text
> # New Ticket Created by bulk88 > # Please include the string: [perl #132955] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=132955 > > > > 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] > > 5.26 (maint-5.26) and 5.27 blead both fail with Win32 VC perl compiled > with USE_CPLUSPLUS=define build option. Solution need backporting to 5.26. > > -------------------------------------- > cl -c -nologo -GF -W3 -TP -EHsc -O1 -MD -Zi -DNDEBUG -GL > -DWIN32 -D_CO > NSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT > -DPERL_IMPLICI > T_SYS -DWIN32_NO_REGISTRY -D_USE_32BIT_TIME_T -O1 -MD -Zi -DNDEBUG -GL > -DVERS > ION=\"1.76\" -DXS_VERSION=\"1.76\" "-I..\..\lib\CORE" POSIX.c > POSIX.c > "..\..\miniperl.exe" "-I..\..\lib" -MExtUtils::Mksymlists \ > -e "Mksymlists('NAME'=>\"POSIX\", 'DLBASE' => 'POSIX', 'DL_FUNCS' > => { }, > 'FUNCLIST' => [], 'IMPORTS' => { }, 'DL_VARS' => []);" > link -out:..\..\lib\auto\POSIX\POSIX.dll -dll -nologo -nodefaultlib > -debug -opt: > ref,icf -ltcg -libpath:"c:\perl\lib\CORE" > -machine:x86 POS > IX.obj "..\..\lib\CORE\perl526.lib" oldnames.lib kernel32.lib > user32.lib gdi32 > .lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib > oleaut32.lib n > etapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib > odbccp3 > 2.lib comctl32.lib msvcrt.lib -def:POSIX.def > Creating library ..\..\lib\auto\POSIX\POSIX.lib and object > ..\..\lib\auto\POS > IX\POSIX.exp > POSIX.obj : error LNK2001: unresolved external symbol _PL_nan > ..\..\lib\auto\POSIX\POSIX.dll : fatal error LNK1120: 1 unresolved externals > dmake: Error code 224, while making '..\..\lib\auto\POSIX\POSIX.dll'
I also see this with VC10 and VC12. With VC14 and VC141 I the build fails earlier with a problem in vutil.c: cl -c -nologo -GF -W3 -TP -EHsc -I..\lib\CORE -I.\include -I. -I.. -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -GL -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -Fo.\mini\util.obj ..\util.c util.c c:\dev\git\perl\vutil.c(696): error C3688: invalid literal suffix 'NVff'; literal operator or literal operator template 'operator ""NVff' not found c:\dev\git\perl\vutil.c(696): error C2664: 'void Perl_sv_catpvf(SV *const ,const char *const ,...)': cannot convert argument 2 from 'NV' to 'const char *const ' c:\dev\git\perl\vutil.c(701): error C3688: invalid literal suffix 'NVff'; literal operator or literal operator template 'operator ""NVff' not found c:\dev\git\perl\vutil.c(701): error C2664: 'int Perl_my_snprintf(char *,const std::size_t,const char *,...)': cannot convert argument 3 from 'NV' to 'const char *' c:\dev\git\perl\vutil.c(992): error C3688: invalid literal suffix 'IVdf'; literal operator or literal operator template 'operator ""IVdf' not found c:\dev\git\perl\vutil.c(996): error C3688: invalid literal suffix 'IVdf'; literal operator or literal operator template 'operator ""IVdf' not found c:\dev\git\perl\vutil.c(996): error C2664: 'void Perl_sv_catpvf(SV *const ,const char *const ,...)': cannot convert argument 2 from 'IV' to 'const char *const ' c:\dev\git\perl\vutil.c(996): note: Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0 \VC\BIN\cl.EXE"' : return code '0x2' Stop. (All these versions of VC work fine without USE_CPLUSPLUS=define.)
To: Steve Hay <steve.m.hay [...] googlemail.com>, perl5-porters [...] perl.org
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: bugs-bitbucket [...] rt.perl.org
Date: Fri, 13 Apr 2018 08:57:01 -0600
On 04/13/2018 02:20 AM, Steve Hay via perl5-porters wrote: Show quoted text
> On 8 March 2018 at 15:57, bulk88 <perlbug-followup@perl.org> wrote:
>> # New Ticket Created by bulk88 >> # Please include the string: [perl #132955] >> # in the subject line of all future correspondence about this issue. >> # <URL: https://rt.perl.org/Ticket/Display.html?id=132955 > >> >> >> 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] >> >> 5.26 (maint-5.26) and 5.27 blead both fail with Win32 VC perl compiled >> with USE_CPLUSPLUS=define build option. Solution need backporting to 5.26. >> >> -------------------------------------- >> cl -c -nologo -GF -W3 -TP -EHsc -O1 -MD -Zi -DNDEBUG -GL >> -DWIN32 -D_CO >> NSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT >> -DPERL_IMPLICI >> T_SYS -DWIN32_NO_REGISTRY -D_USE_32BIT_TIME_T -O1 -MD -Zi -DNDEBUG -GL >> -DVERS >> ION=\"1.76\" -DXS_VERSION=\"1.76\" "-I..\..\lib\CORE" POSIX.c >> POSIX.c >> "..\..\miniperl.exe" "-I..\..\lib" -MExtUtils::Mksymlists \ >> -e "Mksymlists('NAME'=>\"POSIX\", 'DLBASE' => 'POSIX', 'DL_FUNCS' >> => { }, >> 'FUNCLIST' => [], 'IMPORTS' => { }, 'DL_VARS' => []);" >> link -out:..\..\lib\auto\POSIX\POSIX.dll -dll -nologo -nodefaultlib >> -debug -opt: >> ref,icf -ltcg -libpath:"c:\perl\lib\CORE" >> -machine:x86 POS >> IX.obj "..\..\lib\CORE\perl526.lib" oldnames.lib kernel32.lib >> user32.lib gdi32 >> .lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib >> oleaut32.lib n >> etapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib >> odbccp3 >> 2.lib comctl32.lib msvcrt.lib -def:POSIX.def >> Creating library ..\..\lib\auto\POSIX\POSIX.lib and object >> ..\..\lib\auto\POS >> IX\POSIX.exp >> POSIX.obj : error LNK2001: unresolved external symbol _PL_nan >> ..\..\lib\auto\POSIX\POSIX.dll : fatal error LNK1120: 1 unresolved externals >> dmake: Error code 224, while making '..\..\lib\auto\POSIX\POSIX.dll'
> > I also see this with VC10 and VC12. > > With VC14 and VC141 I the build fails earlier with a problem in vutil.c:
What was the latest commit in blead that this was this run on? The first line of the output from ./perl -v would give me the answer Show quoted text
> > cl -c -nologo -GF -W3 -TP -EHsc -I..\lib\CORE -I.\include -I. -I.. > -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE > -D_CRT_NONSTDC_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS > -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -GL -DPERL_EXTERNAL_GLOB > -DPERL_IS_MINIPERL -Fo.\mini\util.obj ..\util.c > util.c > c:\dev\git\perl\vutil.c(696): error C3688: invalid literal suffix > 'NVff'; literal operator or literal operator template 'operator > ""NVff' not found > c:\dev\git\perl\vutil.c(696): error C2664: 'void Perl_sv_catpvf(SV > *const ,const char *const ,...)': cannot convert argument 2 from 'NV' > to 'const char *const ' > c:\dev\git\perl\vutil.c(701): error C3688: invalid literal suffix > 'NVff'; literal operator or literal operator template 'operator > ""NVff' not found > c:\dev\git\perl\vutil.c(701): error C2664: 'int Perl_my_snprintf(char > *,const std::size_t,const char *,...)': cannot convert argument 3 from > 'NV' to 'const char *' > c:\dev\git\perl\vutil.c(992): error C3688: invalid literal suffix > 'IVdf'; literal operator or literal operator template 'operator > ""IVdf' not found > c:\dev\git\perl\vutil.c(996): error C3688: invalid literal suffix > 'IVdf'; literal operator or literal operator template 'operator > ""IVdf' not found > c:\dev\git\perl\vutil.c(996): error C2664: 'void Perl_sv_catpvf(SV > *const ,const char *const ,...)': cannot convert argument 2 from 'IV' > to 'const char *const ' > c:\dev\git\perl\vutil.c(996): note: Conversion from integral type to > pointer type requires reinterpret_cast, C-style cast or function-style > cast > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0 > \VC\BIN\cl.EXE"' : return code '0x2' > Stop. > > (All these versions of VC work fine without USE_CPLUSPLUS=define.) >
Date: Fri, 13 Apr 2018 09:05:29 -0600
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: bugs-bitbucket [...] rt.perl.org
To: Steve Hay <steve.m.hay [...] googlemail.com>, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 492b
On 04/13/2018 08:57 AM, Karl Williamson wrote: Show quoted text
> What was the latest commit in blead that this was this run on?  The > first line of the output from > ./perl -v > would give me the answer
Actually, to save email back-and-forths, if you ran it on the very latest version of blead, as of this moment, with d3a5b29c73b5a2fd6524ca1f8c5c779bd8cb0687 which copied cpan's 'version' onto bleads, that took a step backwards in vutil.c, introducing issues of just the sort that your output shows.
To: Steve Hay <steve.m.hay [...] googlemail.com>, perl5-porters [...] perl.org
Date: Fri, 13 Apr 2018 09:21:38 -0600
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: bugs-bitbucket [...] rt.perl.org
From: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 837b
On 04/13/2018 09:05 AM, Karl Williamson wrote: Show quoted text
> On 04/13/2018 08:57 AM, Karl Williamson wrote:
>> What was the latest commit in blead that this was this run on?  The >> first line of the output from >> ./perl -v >> would give me the answer
> > Actually, to save email back-and-forths, if you ran it on the very > latest version of blead, as of this moment, with > d3a5b29c73b5a2fd6524ca1f8c5c779bd8cb0687 > which copied cpan's 'version' onto bleads, that took a step backwards in > vutil.c, introducing issues of just the sort that your output shows. >
And so, if you run it on blead just prior to that commit, we could see if there are other issues in vutil.c that I don't know about. The maintainer of version, after a hiatus, is currently very involved in fixing it, and so would likely act swiftly to fix anything found.
Date: Fri, 13 Apr 2018 16:24:46 +0100
To: Karl Williamson <public [...] khwilliamson.com>
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
CC: perl5-porters [...] perl.org, bugs-bitbucket [...] rt.perl.org
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
Download (untitled) / with headers
text/plain 1.7k
On 13 April 2018 at 16:21, Karl Williamson <public@khwilliamson.com> wrote: Show quoted text
> On 04/13/2018 09:05 AM, Karl Williamson wrote:
>> >> On 04/13/2018 08:57 AM, Karl Williamson wrote:
>>> >>> What was the latest commit in blead that this was this run on? The first >>> line of the output from >>> ./perl -v >>> would give me the answer
>> >> >> Actually, to save email back-and-forths, if you ran it on the very latest >> version of blead, as of this moment, with >> d3a5b29c73b5a2fd6524ca1f8c5c779bd8cb0687 >> which copied cpan's 'version' onto bleads, that took a step backwards in >> vutil.c, introducing issues of just the sort that your output shows. >>
> > And so, if you run it on blead just prior to that commit, we could see if > there are other issues in vutil.c that I don't know about. The maintainer > of version, after a hiatus, is currently very involved in fixing it, and so > would likely act swiftly to fix anything found.
The result I reported was on d3a5b29c73b5a2fd6524ca1f8c5c779bd8cb0687, which I'd updated to in the hope that it might fix the build since I'd previously tried with the previous commit (1b30b4a8259a74c5ffaee362bc1d881c40fc5279), which had failed like this: cl -c -nologo -GF -W3 -TP -EHsc -I..\lib\CORE -I.\include -I. -I.. -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -GL -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -Fo.\mini\universal.obj ..\universal.c universal.c c:\dev\git\perl\vxs.inc(142): error C3688: invalid literal suffix 'HEKf'; literal operator or literal operator template 'operator ""HEKf' not found NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0 \VC\BIN\cl.EXE"' : return code '0x2' Stop.
To: Steve Hay <steve.m.hay [...] googlemail.com>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: Karl Williamson <public [...] khwilliamson.com>, Perl5 Porters <perl5-porters [...] perl.org>, bugs-bitbucket [...] rt.perl.org
From: Leon Timmermans <fawaka [...] gmail.com>
Date: Fri, 13 Apr 2018 17:36:50 +0200
On Fri, Apr 13, 2018 at 5:24 PM, Steve Hay via perl5-porters <perl5-porters@perl.org> wrote: Show quoted text
> On 13 April 2018 at 16:21, Karl Williamson <public@khwilliamson.com> wrote:
>> On 04/13/2018 09:05 AM, Karl Williamson wrote:
>>> >>> On 04/13/2018 08:57 AM, Karl Williamson wrote:
>>>> >>>> What was the latest commit in blead that this was this run on? The first >>>> line of the output from >>>> ./perl -v >>>> would give me the answer
>>> >>> >>> Actually, to save email back-and-forths, if you ran it on the very latest >>> version of blead, as of this moment, with >>> d3a5b29c73b5a2fd6524ca1f8c5c779bd8cb0687 >>> which copied cpan's 'version' onto bleads, that took a step backwards in >>> vutil.c, introducing issues of just the sort that your output shows. >>>
>> >> And so, if you run it on blead just prior to that commit, we could see if >> there are other issues in vutil.c that I don't know about. The maintainer >> of version, after a hiatus, is currently very involved in fixing it, and so >> would likely act swiftly to fix anything found.
> > The result I reported was on d3a5b29c73b5a2fd6524ca1f8c5c779bd8cb0687, > which I'd updated to in the hope that it might fix the build since I'd > previously tried with the previous commit > (1b30b4a8259a74c5ffaee362bc1d881c40fc5279), which had failed like > this: > > cl -c -nologo -GF -W3 -TP -EHsc -I..\lib\CORE -I.\include -I. -I.. > -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE > -D_CRT_NONSTDC_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS > -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -GL -DPERL_EXTERNAL_GLOB > -DPERL_IS_MINIPERL -Fo.\mini\universal.obj ..\universal.c > universal.c > c:\dev\git\perl\vxs.inc(142): error C3688: invalid literal suffix > 'HEKf'; literal operator or literal operator template 'operator > ""HEKf' not found > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0 > \VC\BIN\cl.EXE"' : return code '0x2' > Stop.
literal operators are a C++11-ism. Adding spaces between a literal string and a term like HEKf or NVff should solve that. Leon
CC: Karl Williamson <public [...] khwilliamson.com>, Perl5 Porters <perl5-porters [...] perl.org>, bugs-bitbucket [...] rt.perl.org
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all5.26 stables
From: James E Keenan <jkeenan [...] pobox.com>
Date: Fri, 13 Apr 2018 15:13:44 -0400
To: Leon Timmermans <fawaka [...] gmail.com>, Steve Hay <steve.m.hay [...] googlemail.com>
Download (untitled) / with headers
text/plain 3.4k
On 04/13/2018 11:36 AM, Leon Timmermans wrote: Show quoted text
> On Fri, Apr 13, 2018 at 5:24 PM, Steve Hay via perl5-porters > <perl5-porters@perl.org> wrote:
>> On 13 April 2018 at 16:21, Karl Williamson <public@khwilliamson.com> wrote:
>>> On 04/13/2018 09:05 AM, Karl Williamson wrote:
>>>> >>>> On 04/13/2018 08:57 AM, Karl Williamson wrote:
>>>>> >>>>> What was the latest commit in blead that this was this run on? The first >>>>> line of the output from >>>>> ./perl -v >>>>> would give me the answer
>>>> >>>> >>>> Actually, to save email back-and-forths, if you ran it on the very latest >>>> version of blead, as of this moment, with >>>> d3a5b29c73b5a2fd6524ca1f8c5c779bd8cb0687 >>>> which copied cpan's 'version' onto bleads, that took a step backwards in >>>> vutil.c, introducing issues of just the sort that your output shows. >>>>
>>> >>> And so, if you run it on blead just prior to that commit, we could see if >>> there are other issues in vutil.c that I don't know about. The maintainer >>> of version, after a hiatus, is currently very involved in fixing it, and so >>> would likely act swiftly to fix anything found.
>> >> The result I reported was on d3a5b29c73b5a2fd6524ca1f8c5c779bd8cb0687, >> which I'd updated to in the hope that it might fix the build since I'd >> previously tried with the previous commit >> (1b30b4a8259a74c5ffaee362bc1d881c40fc5279), which had failed like >> this: >> >> cl -c -nologo -GF -W3 -TP -EHsc -I..\lib\CORE -I.\include -I. -I.. >> -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE >> -D_CRT_NONSTDC_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS >> -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -GL -DPERL_EXTERNAL_GLOB >> -DPERL_IS_MINIPERL -Fo.\mini\universal.obj ..\universal.c >> universal.c >> c:\dev\git\perl\vxs.inc(142): error C3688: invalid literal suffix >> 'HEKf'; literal operator or literal operator template 'operator >> ""HEKf' not found >> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0 >> \VC\BIN\cl.EXE"' : return code '0x2' >> Stop.
> > literal operators are a C++11-ism. Adding spaces between a literal > string and a term like HEKf or NVff should solve that. > > Leon >
This may relate to part of the synching I performed yesterday. Consider this part of commit d3a5b29c73b5a2fd6524ca: ##### diff --git a/vxs.inc b/vxs.inc index 0e5e72a..b5c00d7 100644 --- a/vxs.inc +++ b/vxs.inc @@ -138,7 +138,7 @@ VXS(universal_version) name, SvPVx_nolen_const(req)); #else Perl_croak(aTHX_ - "%" HEKf " does not define $%"HEKf + "%" HEKf " does not define $%" HEKf "::VERSION--version check failed", HEKfARG(name), HEKfARG(name)); #endif ##### This was a case where, prior to this commit, there was a difference between the previous CPAN version and what was in blead. Probably this was why 'vxs.inc' was in the CUSTOMIZED list in the 'version' data in %Modules in Porting/Maintainers.pl. Amid all the other problems I had performing that sync, I decided in this case to go with the maintainer rather than blead. That may well have been the wrong call. If that is so, then what should probably happen is: (a) revert the diff above; (b) test as per the complaint in this ticket; and (c) send what previously was in blead and is once again in blead upstream as a patch. Let me know if you need further assistance. Thank you very much. Jim Keenan
To: James E Keenan <jkeenan [...] pobox.com>
Date: Sat, 14 Apr 2018 00:34:55 +0200
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all5.26 stables
CC: Steve Hay <steve.m.hay [...] googlemail.com>, Karl Williamson <public [...] khwilliamson.com>, Perl5 Porters <perl5-porters [...] perl.org>, bugs-bitbucket [...] rt.perl.org
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 1.6k
On Fri, Apr 13, 2018 at 9:13 PM, James E Keenan <jkeenan@pobox.com> wrote: Show quoted text
> On 04/13/2018 11:36 AM, Leon Timmermans wrote:
>> literal operators are a C++11-ism. Adding spaces between a literal >> string and a term like HEKf or NVff should solve that. >> >> Leon >>
> > This may relate to part of the synching I performed yesterday. Consider > this part of commit d3a5b29c73b5a2fd6524ca: > > ##### > diff --git a/vxs.inc b/vxs.inc > index 0e5e72a..b5c00d7 100644 > --- a/vxs.inc > +++ b/vxs.inc > @@ -138,7 +138,7 @@ VXS(universal_version) > name, SvPVx_nolen_const(req)); > #else > Perl_croak(aTHX_ > - "%" HEKf " does not define $%"HEKf > + "%" HEKf " does not define $%" HEKf > "::VERSION--version check failed", > HEKfARG(name), HEKfARG(name)); > #endif > ##### > > This was a case where, prior to this commit, there was a difference between > the previous CPAN version and what was in blead. Probably this was why > 'vxs.inc' was in the CUSTOMIZED list in the 'version' data in %Modules in > Porting/Maintainers.pl. Amid all the other problems I had performing that > sync, I decided in this case to go with the maintainer rather than blead. > That may well have been the wrong call. > > If that is so, then what should probably happen is: (a) revert the diff > above; (b) test as per the complaint in this ticket; and (c) send what > previously was in blead and is once again in blead upstream as a patch.
I believe the attached patch will fix that issue, but I haven't tested it properly. Leon

Message body is not shown because sender requested not to inline it.

From: Karl Williamson <public [...] khwilliamson.com>
CC: perl5-porters [...] perl.org, bugs-bitbucket [...] rt.perl.org
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
Date: Fri, 13 Apr 2018 22:01:45 -0600
To: Steve Hay <steve.m.hay [...] googlemail.com>
Download (untitled) / with headers
text/plain 1.9k
On 04/13/2018 09:24 AM, Steve Hay wrote: Show quoted text
> On 13 April 2018 at 16:21, Karl Williamson <public@khwilliamson.com> wrote:
>> On 04/13/2018 09:05 AM, Karl Williamson wrote:
>>> >>> On 04/13/2018 08:57 AM, Karl Williamson wrote:
>>>> >>>> What was the latest commit in blead that this was this run on? The first >>>> line of the output from >>>> ./perl -v >>>> would give me the answer
>>> >>> >>> Actually, to save email back-and-forths, if you ran it on the very latest >>> version of blead, as of this moment, with >>> d3a5b29c73b5a2fd6524ca1f8c5c779bd8cb0687 >>> which copied cpan's 'version' onto bleads, that took a step backwards in >>> vutil.c, introducing issues of just the sort that your output shows. >>>
>> >> And so, if you run it on blead just prior to that commit, we could see if >> there are other issues in vutil.c that I don't know about. The maintainer >> of version, after a hiatus, is currently very involved in fixing it, and so >> would likely act swiftly to fix anything found.
> > The result I reported was on d3a5b29c73b5a2fd6524ca1f8c5c779bd8cb0687, > which I'd updated to in the hope that it might fix the build since I'd > previously tried with the previous commit > (1b30b4a8259a74c5ffaee362bc1d881c40fc5279), which had failed like > this: > > cl -c -nologo -GF -W3 -TP -EHsc -I..\lib\CORE -I.\include -I. -I.. > -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE > -D_CRT_NONSTDC_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS > -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -GL -DPERL_EXTERNAL_GLOB > -DPERL_IS_MINIPERL -Fo.\mini\universal.obj ..\universal.c > universal.c > c:\dev\git\perl\vxs.inc(142): error C3688: invalid literal suffix > 'HEKf'; literal operator or literal operator template 'operator > ""HEKf' not found > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0 > \VC\BIN\cl.EXE"' : return code '0x2' > Stop. >
Could you please try it on the branch smoke-me/khw-shay and post any failures?
To: Karl Williamson <public [...] khwilliamson.com>
Date: Sat, 14 Apr 2018 13:51:40 +0100
From: Steve Hay <steve.m.hay [...] googlemail.com>
CC: perl5-porters [...] perl.org, bugs-bitbucket [...] rt.perl.org
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
Download (untitled) / with headers
text/plain 3.1k
On 14 April 2018 at 05:01, Karl Williamson <public@khwilliamson.com> wrote: Show quoted text
> On 04/13/2018 09:24 AM, Steve Hay wrote:
>> >> On 13 April 2018 at 16:21, Karl Williamson <public@khwilliamson.com> >> wrote:
>>> >>> On 04/13/2018 09:05 AM, Karl Williamson wrote:
>>>> >>>> >>>> On 04/13/2018 08:57 AM, Karl Williamson wrote:
>>>>> >>>>> >>>>> What was the latest commit in blead that this was this run on? The >>>>> first >>>>> line of the output from >>>>> ./perl -v >>>>> would give me the answer
>>>> >>>> >>>> >>>> Actually, to save email back-and-forths, if you ran it on the very >>>> latest >>>> version of blead, as of this moment, with >>>> d3a5b29c73b5a2fd6524ca1f8c5c779bd8cb0687 >>>> which copied cpan's 'version' onto bleads, that took a step backwards in >>>> vutil.c, introducing issues of just the sort that your output shows. >>>>
>>> >>> And so, if you run it on blead just prior to that commit, we could see if >>> there are other issues in vutil.c that I don't know about. The >>> maintainer >>> of version, after a hiatus, is currently very involved in fixing it, and >>> so >>> would likely act swiftly to fix anything found.
>> >> >> The result I reported was on d3a5b29c73b5a2fd6524ca1f8c5c779bd8cb0687, >> which I'd updated to in the hope that it might fix the build since I'd >> previously tried with the previous commit >> (1b30b4a8259a74c5ffaee362bc1d881c40fc5279), which had failed like >> this: >> >> cl -c -nologo -GF -W3 -TP -EHsc -I..\lib\CORE -I.\include -I. -I.. >> -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE >> -D_CRT_NONSTDC_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS >> -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -GL -DPERL_EXTERNAL_GLOB >> -DPERL_IS_MINIPERL -Fo.\mini\universal.obj ..\universal.c >> universal.c >> c:\dev\git\perl\vxs.inc(142): error C3688: invalid literal suffix >> 'HEKf'; literal operator or literal operator template 'operator >> ""HEKf' not found >> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual >> Studio 14.0 >> \VC\BIN\cl.EXE"' : return code '0x2' >> Stop. >>
> > Could you please try it on the branch smoke-me/khw-shay and post any > failures? >
On that branch, both universal.c and util.c now compile but now we run into a different (unrelated) problem instead: cl -c -nologo -GF -W3 -TP -EHsc -I..\lib\CORE -I.\include -I. -I.. -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -GL -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -Fo.\mini\perlio.obj ..\perlio.c perlio.c ..\perlio.c(3227): error C2106: '=': left operand must be l-value NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0 \VC\BIN\cl.EXE"' : return code '0x2' Stop. I obviously haven't tried a C++ build with VS2015 since adding support for that compiler :-/ The line it complains about is: PERLIO_FILE_file(f) = -1; For VS2015 and higher, win32/win32.h has: #define PERLIO_FILE_file(f) ((int)(((__crt_stdio_stream_data*)(f))->_file)) which is fine in a C build, but evidently not C++. Sigh... Your changes to the version distro seem good, though, so it would be worthwhile getting them taken on board upstream. Thanks.
Date: Sat, 14 Apr 2018 10:38:46 -0600
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all5.26 stables
CC: Steve Hay <steve.m.hay [...] googlemail.com>, Perl5 Porters <perl5-porters [...] perl.org>, bugs-bitbucket [...] rt.perl.org
From: Karl Williamson <public [...] khwilliamson.com>
To: Leon Timmermans <fawaka [...] gmail.com>, James E Keenan <jkeenan [...] pobox.com>
Download (untitled) / with headers
text/plain 2.2k
On 04/13/2018 04:34 PM, Leon Timmermans wrote: Show quoted text
> On Fri, Apr 13, 2018 at 9:13 PM, James E Keenan <jkeenan@pobox.com> wrote:
>> On 04/13/2018 11:36 AM, Leon Timmermans wrote:
>>> literal operators are a C++11-ism. Adding spaces between a literal >>> string and a term like HEKf or NVff should solve that. >>> >>> Leon >>>
>> >> This may relate to part of the synching I performed yesterday. Consider >> this part of commit d3a5b29c73b5a2fd6524ca: >> >> ##### >> diff --git a/vxs.inc b/vxs.inc >> index 0e5e72a..b5c00d7 100644 >> --- a/vxs.inc >> +++ b/vxs.inc >> @@ -138,7 +138,7 @@ VXS(universal_version) >> name, SvPVx_nolen_const(req)); >> #else >> Perl_croak(aTHX_ >> - "%" HEKf " does not define $%"HEKf >> + "%" HEKf " does not define $%" HEKf >> "::VERSION--version check failed", >> HEKfARG(name), HEKfARG(name)); >> #endif >> ##### >> >> This was a case where, prior to this commit, there was a difference between >> the previous CPAN version and what was in blead. Probably this was why >> 'vxs.inc' was in the CUSTOMIZED list in the 'version' data in %Modules in >> Porting/Maintainers.pl. Amid all the other problems I had performing that >> sync, I decided in this case to go with the maintainer rather than blead. >> That may well have been the wrong call. >> >> If that is so, then what should probably happen is: (a) revert the diff >> above; (b) test as per the complaint in this ticket; and (c) send what >> previously was in blead and is once again in blead upstream as a patch.
> > I believe the attached patch will fix that issue, but I haven't tested > it properly. > > Leon >
Yes, the issue is a result of the cpan overwrite of what is in blead. Leon's patch isn't necessary, as I had already sent an equivalent patch to the maintainer, and that got applied and pushed into what Jim merged. The problem, which I alluded to in my post, is that vutil.c lost some necessary white space. That white space was included in a previous version of vutil.c, and I suspect the reason it got lost is that there are currently two repositories of 'version', and it was only in one. I have emailed a patch to the maintainer.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.7k
On Sat, 14 Apr 2018 16:39:11 GMT, public@khwilliamson.com wrote: Show quoted text
> On 04/13/2018 04:34 PM, Leon Timmermans wrote:
> > On Fri, Apr 13, 2018 at 9:13 PM, James E Keenan <jkeenan@pobox.com> > > wrote:
> >> On 04/13/2018 11:36 AM, Leon Timmermans wrote:
> >>> literal operators are a C++11-ism. Adding spaces between a literal > >>> string and a term like HEKf or NVff should solve that. > >>> > >>> Leon > >>>
> >> > >> This may relate to part of the synching I performed yesterday. > >> Consider > >> this part of commit d3a5b29c73b5a2fd6524ca: > >> > >> ##### > >> diff --git a/vxs.inc b/vxs.inc > >> index 0e5e72a..b5c00d7 100644 > >> --- a/vxs.inc > >> +++ b/vxs.inc > >> @@ -138,7 +138,7 @@ VXS(universal_version) > >> name, SvPVx_nolen_const(req)); > >> #else > >> Perl_croak(aTHX_ > >> - "%" HEKf " does not define $%"HEKf > >> + "%" HEKf " does not define $%" HEKf > >> "::VERSION--version check failed", > >> HEKfARG(name), HEKfARG(name)); > >> #endif > >> ##### > >> > >> This was a case where, prior to this commit, there was a difference > >> between > >> the previous CPAN version and what was in blead. Probably this was > >> why > >> 'vxs.inc' was in the CUSTOMIZED list in the 'version' data in > >> %Modules in > >> Porting/Maintainers.pl. Amid all the other problems I had > >> performing that > >> sync, I decided in this case to go with the maintainer rather than > >> blead. > >> That may well have been the wrong call. > >> > >> If that is so, then what should probably happen is: (a) revert the > >> diff > >> above; (b) test as per the complaint in this ticket; and (c) send > >> what > >> previously was in blead and is once again in blead upstream as a > >> patch.
> > > > I believe the attached patch will fix that issue, but I haven't > > tested > > it properly. > > > > Leon > >
> > Yes, the issue is a result of the cpan overwrite of what is in blead. > Leon's patch isn't necessary, as I had already sent an equivalent > patch > to the maintainer, and that got applied and pushed into what Jim > merged. > > The problem, which I alluded to in my post, is that vutil.c lost some > necessary white space. That white space was included in a previous > version of vutil.c, and I suspect the reason it got lost is that there > are currently two repositories of 'version', and it was only in one. > I > have emailed a patch to the maintainer.
(09:22:14 PM) ***p5commits James Keenan pushed to blead (v5.27.10-136-ga684213360): John Peacock: Synch cpan/version/* and other files with CPAN version 0.9923.; https://perl5.git.perl.org/perl.git/commitdiff/a6842133 -- James E Keenan (jkeenan@cpan.org)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.9k
On Sun, 15 Apr 2018 18:24:06 -0700, jkeenan wrote: Show quoted text
> On Sat, 14 Apr 2018 16:39:11 GMT, public@khwilliamson.com wrote:
> > On 04/13/2018 04:34 PM, Leon Timmermans wrote:
> > > On Fri, Apr 13, 2018 at 9:13 PM, James E Keenan <jkeenan@pobox.com> > > > wrote:
> > >> On 04/13/2018 11:36 AM, Leon Timmermans wrote:
> > >>> literal operators are a C++11-ism. Adding spaces between a > > >>> literal > > >>> string and a term like HEKf or NVff should solve that. > > >>> > > >>> Leon > > >>>
> > >> > > >> This may relate to part of the synching I performed yesterday. > > >> Consider > > >> this part of commit d3a5b29c73b5a2fd6524ca: > > >> > > >> ##### > > >> diff --git a/vxs.inc b/vxs.inc > > >> index 0e5e72a..b5c00d7 100644 > > >> --- a/vxs.inc > > >> +++ b/vxs.inc > > >> @@ -138,7 +138,7 @@ VXS(universal_version) > > >> name, SvPVx_nolen_const(req)); > > >> #else > > >> Perl_croak(aTHX_ > > >> - "%" HEKf " does not define $%"HEKf > > >> + "%" HEKf " does not define $%" HEKf > > >> "::VERSION--version check failed", > > >> HEKfARG(name), HEKfARG(name)); > > >> #endif > > >> ##### > > >> > > >> This was a case where, prior to this commit, there was a > > >> difference > > >> between > > >> the previous CPAN version and what was in blead. Probably this > > >> was > > >> why > > >> 'vxs.inc' was in the CUSTOMIZED list in the 'version' data in > > >> %Modules in > > >> Porting/Maintainers.pl. Amid all the other problems I had > > >> performing that > > >> sync, I decided in this case to go with the maintainer rather than > > >> blead. > > >> That may well have been the wrong call. > > >> > > >> If that is so, then what should probably happen is: (a) revert the > > >> diff > > >> above; (b) test as per the complaint in this ticket; and (c) send > > >> what > > >> previously was in blead and is once again in blead upstream as a > > >> patch.
> > > > > > I believe the attached patch will fix that issue, but I haven't > > > tested > > > it properly. > > > > > > Leon > > >
> > > > Yes, the issue is a result of the cpan overwrite of what is in blead. > > Leon's patch isn't necessary, as I had already sent an equivalent > > patch > > to the maintainer, and that got applied and pushed into what Jim > > merged. > > > > The problem, which I alluded to in my post, is that vutil.c lost some > > necessary white space. That white space was included in a previous > > version of vutil.c, and I suspect the reason it got lost is that > > there > > are currently two repositories of 'version', and it was only in one. > > I > > have emailed a patch to the maintainer.
> > (09:22:14 PM) ***p5commits James Keenan pushed to blead (v5.27.10-136- > ga684213360): John Peacock: Synch cpan/version/* and other files with > CPAN version 0.9923.; > https://perl5.git.perl.org/perl.git/commitdiff/a6842133
So should this be resolved?
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
CC: perl5-porters [...] perl.org
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
Date: Thu, 19 Apr 2018 17:25:11 +0100
Download (untitled) / with headers
text/plain 3.1k
On 19 April 2018 at 17:17, Sawyer X via RT <perlbug-followup@perl.org> wrote: Show quoted text
> On Sun, 15 Apr 2018 18:24:06 -0700, jkeenan wrote:
>> On Sat, 14 Apr 2018 16:39:11 GMT, public@khwilliamson.com wrote:
>> > On 04/13/2018 04:34 PM, Leon Timmermans wrote:
>> > > On Fri, Apr 13, 2018 at 9:13 PM, James E Keenan <jkeenan@pobox.com> >> > > wrote:
>> > >> On 04/13/2018 11:36 AM, Leon Timmermans wrote:
>> > >>> literal operators are a C++11-ism. Adding spaces between a >> > >>> literal >> > >>> string and a term like HEKf or NVff should solve that. >> > >>> >> > >>> Leon >> > >>>
>> > >> >> > >> This may relate to part of the synching I performed yesterday. >> > >> Consider >> > >> this part of commit d3a5b29c73b5a2fd6524ca: >> > >> >> > >> ##### >> > >> diff --git a/vxs.inc b/vxs.inc >> > >> index 0e5e72a..b5c00d7 100644 >> > >> --- a/vxs.inc >> > >> +++ b/vxs.inc >> > >> @@ -138,7 +138,7 @@ VXS(universal_version) >> > >> name, SvPVx_nolen_const(req)); >> > >> #else >> > >> Perl_croak(aTHX_ >> > >> - "%" HEKf " does not define $%"HEKf >> > >> + "%" HEKf " does not define $%" HEKf >> > >> "::VERSION--version check failed", >> > >> HEKfARG(name), HEKfARG(name)); >> > >> #endif >> > >> ##### >> > >> >> > >> This was a case where, prior to this commit, there was a >> > >> difference >> > >> between >> > >> the previous CPAN version and what was in blead. Probably this >> > >> was >> > >> why >> > >> 'vxs.inc' was in the CUSTOMIZED list in the 'version' data in >> > >> %Modules in >> > >> Porting/Maintainers.pl. Amid all the other problems I had >> > >> performing that >> > >> sync, I decided in this case to go with the maintainer rather than >> > >> blead. >> > >> That may well have been the wrong call. >> > >> >> > >> If that is so, then what should probably happen is: (a) revert the >> > >> diff >> > >> above; (b) test as per the complaint in this ticket; and (c) send >> > >> what >> > >> previously was in blead and is once again in blead upstream as a >> > >> patch.
>> > > >> > > I believe the attached patch will fix that issue, but I haven't >> > > tested >> > > it properly. >> > > >> > > Leon >> > >
>> > >> > Yes, the issue is a result of the cpan overwrite of what is in blead. >> > Leon's patch isn't necessary, as I had already sent an equivalent >> > patch >> > to the maintainer, and that got applied and pushed into what Jim >> > merged. >> > >> > The problem, which I alluded to in my post, is that vutil.c lost some >> > necessary white space. That white space was included in a previous >> > version of vutil.c, and I suspect the reason it got lost is that >> > there >> > are currently two repositories of 'version', and it was only in one. >> > I >> > have emailed a patch to the maintainer.
>> >> (09:22:14 PM) ***p5commits James Keenan pushed to blead (v5.27.10-136- >> ga684213360): John Peacock: Synch cpan/version/* and other files with >> CPAN version 0.9923.; >> https://perl5.git.perl.org/perl.git/commitdiff/a6842133
> > So should this be resolved? >
Not yet, no - there is still the PERLIO_FILE_file() problem, which was nothing to do with version.pm.
Date: Thu, 19 Apr 2018 19:33:33 +0200
From: Leon Timmermans <fawaka [...] gmail.com>
CC: Perl RT Bug Tracker <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
To: Steve Hay <steve.m.hay [...] googlemail.com>
Download (untitled) / with headers
text/plain 326b
On Thu, Apr 19, 2018 at 6:25 PM, Steve Hay via perl5-porters <perl5-porters@perl.org> wrote: Show quoted text
> Not yet, no - there is still the PERLIO_FILE_file() problem, which was > nothing to do with version.pm.
I don't quite understand why it's accepting that in C mode, casts shouldn't be lvalue. Wouldn't the attached fix that? Leon

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 3.4k
On Thu, 19 Apr 2018 09:17:31 -0700, xsawyerx@cpan.org wrote: Show quoted text
> On Sun, 15 Apr 2018 18:24:06 -0700, jkeenan wrote:
> > On Sat, 14 Apr 2018 16:39:11 GMT, public@khwilliamson.com wrote:
> > > On 04/13/2018 04:34 PM, Leon Timmermans wrote:
> > > > On Fri, Apr 13, 2018 at 9:13 PM, James E Keenan <jkeenan@pobox.com> > > > > wrote:
> > > >> On 04/13/2018 11:36 AM, Leon Timmermans wrote:
> > > >>> literal operators are a C++11-ism. Adding spaces between a > > > >>> literal > > > >>> string and a term like HEKf or NVff should solve that. > > > >>> > > > >>> Leon > > > >>>
> > > >> > > > >> This may relate to part of the synching I performed yesterday. > > > >> Consider > > > >> this part of commit d3a5b29c73b5a2fd6524ca: > > > >> > > > >> ##### > > > >> diff --git a/vxs.inc b/vxs.inc > > > >> index 0e5e72a..b5c00d7 100644 > > > >> --- a/vxs.inc > > > >> +++ b/vxs.inc > > > >> @@ -138,7 +138,7 @@ VXS(universal_version) > > > >> name, SvPVx_nolen_const(req)); > > > >> #else > > > >> Perl_croak(aTHX_ > > > >> - "%" HEKf " does not define $%"HEKf > > > >> + "%" HEKf " does not define $%" HEKf > > > >> "::VERSION--version check failed", > > > >> HEKfARG(name), HEKfARG(name)); > > > >> #endif > > > >> ##### > > > >> > > > >> This was a case where, prior to this commit, there was a > > > >> difference > > > >> between > > > >> the previous CPAN version and what was in blead. Probably this > > > >> was > > > >> why > > > >> 'vxs.inc' was in the CUSTOMIZED list in the 'version' data in > > > >> %Modules in > > > >> Porting/Maintainers.pl. Amid all the other problems I had > > > >> performing that > > > >> sync, I decided in this case to go with the maintainer rather than > > > >> blead. > > > >> That may well have been the wrong call. > > > >> > > > >> If that is so, then what should probably happen is: (a) revert the > > > >> diff > > > >> above; (b) test as per the complaint in this ticket; and (c) send > > > >> what > > > >> previously was in blead and is once again in blead upstream as a > > > >> patch.
> > > > > > > > I believe the attached patch will fix that issue, but I haven't > > > > tested > > > > it properly. > > > > > > > > Leon > > > >
> > > > > > Yes, the issue is a result of the cpan overwrite of what is in blead. > > > Leon's patch isn't necessary, as I had already sent an equivalent > > > patch > > > to the maintainer, and that got applied and pushed into what Jim > > > merged. > > > > > > The problem, which I alluded to in my post, is that vutil.c lost some > > > necessary white space. That white space was included in a previous > > > version of vutil.c, and I suspect the reason it got lost is that > > > there > > > are currently two repositories of 'version', and it was only in one. > > > I > > > have emailed a patch to the maintainer.
> > > > (09:22:14 PM) ***p5commits James Keenan pushed to blead (v5.27.10-136- > > ga684213360): John Peacock: Synch cpan/version/* and other files with > > CPAN version 0.9923.; > > https://perl5.git.perl.org/perl.git/commitdiff/a6842133
> > So should this be resolved?
I still can't build C++ perl because of PL_nan wrong declaration by jhi https://perl5.git.perl.org/perl.git/commitdiff/0879cd66ef3f00918ae26d9bb7ac555d3911c548 . The lvalue cast and C++11 postfix operator space issues were found by others, not me. -- bulk88 ~ bulk88 at hotmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.1k
On Thu, 19 Apr 2018 23:08:56 -0700, bulk88 wrote: Show quoted text
> I still can't build C++ perl because of PL_nan wrong declaration by > jhi > https://perl5.git.perl.org/perl.git/commitdiff/0879cd66ef3f00918ae26d9bb7ac555d3911c548 > . The lvalue cast and C++11 postfix operator space issues were found > by others, not me.
I'm starting to think https://perl5.git.perl.org/perl.git/commitdiff/0879cd66ef3f00918ae26d9bb7ac555d3911c548 needs to be reverted outright. PL_nan/PL_inf must be either const and in globvar.sym or perlvars.h and RT inited. There are only 2 kinds of global vars in perl API. PL_nan/PL_inf should match existing infrastructure. Not special casing itself. Something about the jhi vax-netbsd series of commits doesn't make sense. On a C++ build, why does it matter if perl's core symbols are C mangled or C++ mangled by the CC/LD, aslong as its all declared the same way in every .o? How does the rest of globvar.sym global vars work with just EXTCONST (C++ sym name) but not "EXTERN_C const" on vax-netbsd platform? Is POSIX.xs compiled in C mode even on a C++ perl or something with EUMM CFLAGS changes? Is anyone but JHI able to compile perl for vax-netbsd? -- bulk88 ~ bulk88 at hotmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 468b
On Thu, 19 Apr 2018 10:34:04 -0700, LeonT wrote: Show quoted text
> On Thu, Apr 19, 2018 at 6:25 PM, Steve Hay via perl5-porters > <perl5-porters@perl.org> wrote:
> > Not yet, no - there is still the PERLIO_FILE_file() problem, which was > > nothing to do with version.pm.
> > I don't quite understand why it's accepting that in C mode, casts > shouldn't be lvalue. > > Wouldn't the attached fix that? >
Yes. Thanks - now applied in commit 002a84150d55738667ea8a7243b124db949436ca.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Fri, 20 Apr 2018 17:23:46 -0700, bulk88 wrote: Show quoted text
> On Thu, 19 Apr 2018 23:08:56 -0700, bulk88 wrote:
> > I still can't build C++ perl because of PL_nan wrong declaration by > > jhi > > https://perl5.git.perl.org/perl.git/commitdiff/0879cd66ef3f00918ae26d9bb7ac555d3911c548 > > . The lvalue cast and C++11 postfix operator space issues were found > > by others, not me.
> > I'm starting to think > https://perl5.git.perl.org/perl.git/commitdiff/0879cd66ef3f00918ae26d9bb7ac555d3911c548 > needs to be reverted outright. PL_nan/PL_inf must be either const and > in globvar.sym or perlvars.h and RT inited. There are only 2 kinds of > global vars in perl API. PL_nan/PL_inf should match existing > infrastructure. Not special casing itself. Something about the jhi > vax-netbsd series of commits doesn't make sense. On a C++ build, why > does it matter if perl's core symbols are C mangled or C++ mangled by > the CC/LD, aslong as its all declared the same way in every .o? How > does the rest of globvar.sym global vars work with just EXTCONST (C++ > sym name) but not "EXTERN_C const" on vax-netbsd platform? Is POSIX.xs > compiled in C mode even on a C++ perl or something with EUMM CFLAGS > changes? Is anyone but JHI able to compile perl for vax-netbsd?
I asked Jarkko about that commit. He suggested reverting it, but double checking that the whole thing then still builds also for Linux using g++. Is anyone able to do that? (Presumably I could do it on dromedary, but wouldn't really know what I'm doing -- I've not built perl on anything UNIXy for many, many years.)
To: Steve Hay via RT <perlbug-followup [...] perl.org>
From: Dave Mitchell <davem [...] iabyn.com>
CC: perl5-porters [...] perl.org
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
Date: Mon, 23 Apr 2018 14:38:58 +0100
Download (untitled) / with headers
text/plain 1.8k
On Mon, Apr 23, 2018 at 05:59:21AM -0700, Steve Hay via RT wrote: Show quoted text
> On Fri, 20 Apr 2018 17:23:46 -0700, bulk88 wrote:
> > On Thu, 19 Apr 2018 23:08:56 -0700, bulk88 wrote:
> > > I still can't build C++ perl because of PL_nan wrong declaration by > > > jhi > > > https://perl5.git.perl.org/perl.git/commitdiff/0879cd66ef3f00918ae26d9bb7ac555d3911c548 > > > . The lvalue cast and C++11 postfix operator space issues were found > > > by others, not me.
> > > > I'm starting to think > > https://perl5.git.perl.org/perl.git/commitdiff/0879cd66ef3f00918ae26d9bb7ac555d3911c548 > > needs to be reverted outright. PL_nan/PL_inf must be either const and > > in globvar.sym or perlvars.h and RT inited. There are only 2 kinds of > > global vars in perl API. PL_nan/PL_inf should match existing > > infrastructure. Not special casing itself. Something about the jhi > > vax-netbsd series of commits doesn't make sense. On a C++ build, why > > does it matter if perl's core symbols are C mangled or C++ mangled by > > the CC/LD, aslong as its all declared the same way in every .o? How > > does the rest of globvar.sym global vars work with just EXTCONST (C++ > > sym name) but not "EXTERN_C const" on vax-netbsd platform? Is POSIX.xs > > compiled in C mode even on a C++ perl or something with EUMM CFLAGS > > changes? Is anyone but JHI able to compile perl for vax-netbsd?
> > I asked Jarkko about that commit. He suggested reverting it, but double checking that the whole thing then still builds also for Linux using g++. > > Is anyone able to do that? (Presumably I could do it on dromedary, but wouldn't really know what I'm doing -- I've not built perl on anything UNIXy for many, many years.)
I'll have a look -- All wight. I will give you one more chance. This time, I want to hear no Wubens. No Weginalds. No Wudolf the wed-nosed weindeers. -- Life of Brian
Date: Mon, 23 Apr 2018 15:01:59 +0100
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: perl5-porters [...] perl.org
From: Dave Mitchell <davem [...] iabyn.com>
To: Steve Hay via RT <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 770b
Show quoted text
> > I asked Jarkko about that commit. He suggested reverting it, but double checking that the whole thing then still builds also for Linux using g++. > > > > Is anyone able to do that? (Presumably I could do it on dromedary, but wouldn't really know what I'm doing -- I've not built perl on anything UNIXy for many, many years.)
> > I'll have a look
Well, a simple revert caused g++ to break on linux: In file included from POSIX.xs:19:0: ../../perl.h:6792:19: error: ‘const<unnamed union> PL_nan’, declared using unnamed type, is used but never defined [-fpermissive] INFNAN_NV_U8_DECL PL_nan; ^~~~~~ I haven't looked any further yet. -- A walk of a thousand miles begins with a single step... then continues for another 1,999,999 or so.
From: Dave Mitchell <davem [...] iabyn.com>
CC: perl5-porters [...] perl.org
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
To: Steve Hay via RT <perlbug-followup [...] perl.org>
Date: Tue, 24 Apr 2018 11:52:22 +0100
Download (untitled) / with headers
text/plain 1.6k
On Mon, Apr 23, 2018 at 03:01:59PM +0100, Dave Mitchell wrote: Show quoted text
> > > I asked Jarkko about that commit. He suggested reverting it, but double checking that the whole thing then still builds also for Linux using g++. > > > > > > Is anyone able to do that? (Presumably I could do it on dromedary, but wouldn't really know what I'm doing -- I've not built perl on anything UNIXy for many, many years.)
> > > > I'll have a look
> > Well, a simple revert caused g++ to break on linux: > > In file included from POSIX.xs:19:0: > ../../perl.h:6792:19: error: ‘const<unnamed union> PL_nan’, declared using unnamed type, is used but never defined [-fpermissive] > INFNAN_NV_U8_DECL PL_nan; > ^~~~~~ > I haven't looked any further yet.
In more detail: before jhi's C++ fix, the declaration of PL_nan expanded to: extern const union { NV nv; U8 u8[8]; } PL_nan; and (under g++) gave this warning on the core *.c files: perl.h:6792:19: warning: unnamed type with no linkage used to declare variable ‘const<unnamed union> PL_nan’ with linkage and this error on POSIX.i (when including perl.h): ../../perl.h:6792:19: error: ‘const<unnamed union> PL_nan’, declared using unnamed type, is used but never defined [-fpermissive] jhi changed the declaration under C++ to expand to: extern "C" const union { NV nv; U8 u8[8]; } PL_nan; and the warnings/errors went away on Linux, but broke Windows. Does anyone with knowledge about C++ and linking have any clue what this all means? -- "You're so sadly neglected, and often ignored. A poor second to Belgium, When going abroad." -- Monty Python, "Finland"
From: Leon Timmermans <fawaka [...] gmail.com>
CC: Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
To: Dave Mitchell <davem [...] iabyn.com>
Date: Tue, 24 Apr 2018 14:56:00 +0200
Download (untitled) / with headers
text/plain 1.7k
On Tue, Apr 24, 2018 at 12:52 PM, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Mon, Apr 23, 2018 at 03:01:59PM +0100, Dave Mitchell wrote:
>> > > I asked Jarkko about that commit. He suggested reverting it, but double checking that the whole thing then still builds also for Linux using g++. >> > > >> > > Is anyone able to do that? (Presumably I could do it on dromedary, but wouldn't really know what I'm doing -- I've not built perl on anything UNIXy for many, many years.)
>> > >> > I'll have a look
>> >> Well, a simple revert caused g++ to break on linux: >> >> In file included from POSIX.xs:19:0: >> ../../perl.h:6792:19: error: ‘const<unnamed union> PL_nan’, declared using unnamed type, is used but never defined [-fpermissive] >> INFNAN_NV_U8_DECL PL_nan; >> ^~~~~~ >> I haven't looked any further yet.
> > In more detail: > > before jhi's C++ fix, the declaration of PL_nan expanded to: > > extern const union { NV nv; U8 u8[8]; } PL_nan; > > and (under g++) gave this warning on the core *.c files: > > perl.h:6792:19: warning: unnamed type with no linkage used to declare variable ‘const<unnamed union> PL_nan’ with linkage > > and this error on POSIX.i (when including perl.h): > > ../../perl.h:6792:19: error: ‘const<unnamed union> PL_nan’, declared using unnamed type, is used but never defined [-fpermissive] > > jhi changed the declaration under C++ to expand to: > > extern "C" const union { NV nv; U8 u8[8]; } PL_nan; > > > and the warnings/errors went away on Linux, but broke Windows. > > Does anyone with knowledge about C++ and linking have any clue what this > all means?
I would guess that making them EXTCONST again, but putting them inside a START_EXTERN_C/END_EXTERN_C block would fix this. Leon
Date: Tue, 24 Apr 2018 15:49:53 +0100
To: Leon Timmermans <fawaka [...] gmail.com>
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 571b
On Tue, Apr 24, 2018 at 02:56:00PM +0200, Leon Timmermans wrote: Show quoted text
> I would guess that making them EXTCONST again, but putting them inside > a START_EXTERN_C/END_EXTERN_C block would fix this.
That seems to work under linux. This branch I've just pushed, smoke-me/davem/nan_cpp, builds ok with gcc, g++ and clang on Linux. Does someone want to try it on Windows? -- Wesley Crusher gets beaten up by his classmates for being a smarmy git, and consequently has a go at making some friends of his own age for a change. -- Things That Never Happen in "Star Trek" #18
To: Dave Mitchell <davem [...] iabyn.com>
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
CC: Leon Timmermans <fawaka [...] gmail.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
Date: Tue, 24 Apr 2018 17:23:25 +0100
Download (untitled) / with headers
text/plain 1.7k
On 24 April 2018 at 15:49, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Tue, Apr 24, 2018 at 02:56:00PM +0200, Leon Timmermans wrote: >
>> I would guess that making them EXTCONST again, but putting them inside >> a START_EXTERN_C/END_EXTERN_C block would fix this.
> > That seems to work under linux. > This branch I've just pushed, smoke-me/davem/nan_cpp, > builds ok with gcc, g++ and clang on Linux. > > Does someone want to try it on Windows? >
That fixes the problem for me. But I spoke to soon in claiming that the build otherwise worked with VS2017. There is still one more problem: Socket.xs(804): error C2132: syntax error: unexpected identifier Socket.xs(808): error C2132: syntax error: unexpected identifier I don't understand this one either. Line 804 is: if (sockaddr_len < STRUCT_OFFSET(struct sockaddr, sa_data)) which pre-processes to: if (sockaddr_len < __builtin_offsetof(struct sockaddr,sa_data)) Similar pre-processing happens in many other files and they compile without trouble, e.g. in B.xs we have: { STR_WITH_LEN("next"), OPp, STRUCT_OFFSET(struct op, op_next), }, which becomes: { ("" "next" ""), (sizeof("next")-1), 0x3, __builtin_offsetof(struct op,op_next), }, and causes no problem. I can't see why Socket is any different. However, It does contain this: /* STRUCT_OFFSET should have come from from perl.h, but if not, * roll our own (not using offsetof() since that is C99). */ #ifndef STRUCT_OFFSET # define STRUCT_OFFSET(s,m) (Size_t)(&(((s *)0)->m)) #endif and if I insert "#undef STRUCT_OFFSET" before that (to get rid of the definition from perl.h and use the above instead) then it fixes it. That can't be the right solution, though. *That* really is the last problem. With that hack in place the build now succeeds.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 676b
On Tue, 24 Apr 2018 09:23:38 -0700, shay wrote: Show quoted text
> *That* really is the last problem. With that hack in place the build > now succeeds.
You didn't try Mingw C++ builds, only VC. Here is a patch that fixed C++ problems on 32b gcc. I wasn't able to test it on 64b gcc. The warnings in plain C I saw for a long time but I never researched or paid attention to it, and it seems to have never caused any test fails but IDK how it didn't cause test fails (I'd have to step the asm code with a debugger and see if by chance the broken hexadecimal sequence by chance is still NAN/INF when the byte sequence is reinterpreted as a 8 byte FP double). -- bulk88 ~ bulk88 at hotmail.com
Subject: 0001-fix-Mingw-GCC-C-build-errors-PL_inf-PL_nan.patch
From 233e3bfb5523d730c38f039e1866fbbaef7bc71e Mon Sep 17 00:00:00 2001 From: Daniel Dragan <bulk88@hotmail.com> Date: Tue, 24 Apr 2018 14:12:46 -0400 Subject: [PATCH] fix Mingw GCC C++ build errors PL_inf/PL_nan Trying a USE_CPLUSPLUS=define build with dmake (USE_CPLUSPLUS not implemented in GNUMakefile) causes the following error --------- gcc -c -xc++ -I.\include -I. -I.. -DWIN32 -DPERLDLL -DPERL_CORE -s -O2 -fwrapv - fno-strict-aliasing -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -omini\globals.o .. \globals.c In file included from ..\globals.c:32:0: ..\perl.h:6754:50: error: too many initializers for 'U8 [8] {aka unsigned char [ 8]}' INFNAN_U8_NV_DECL PL_inf = { { LONGDBLINFBYTES } }; ^ ..\perl.h:6790:50: error: too many initializers for 'U8 [8] {aka unsigned char [ 8]}' INFNAN_U8_NV_DECL PL_nan = { { LONGDBLNANBYTES } }; ^ dmake: Error code 129, while making 'mini\globals.o' --------- in plain C mode builds, this error was just a warning and nobody paid attention to it for a while --------- gcc -c -I.\include -I. -I.. -DWIN32 -DPERLDLL -DPERL_CORE -s -O2 -fwrapv -fno-s trict-aliasing -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -omini\globals.o ..\glob als.c In file included from ..\globals.c:32:0: ..\perl.h:5432:42: warning: excess elements in array initializer #define INFNAN_U8_NV_DECL EXTCONST union { U8 u8[NVSIZE]; NV nv; } ^ ..\perl.h:6754:1: note: in expansion of macro 'INFNAN_U8_NV_DECL' INFNAN_U8_NV_DECL PL_inf = { { LONGDBLINFBYTES } }; ^ ..\perl.h:5432:42: warning: (near initialization for 'PL_inf.u8') #define INFNAN_U8_NV_DECL EXTCONST union { U8 u8[NVSIZE]; NV nv; } ^ ..\perl.h:6754:1: note: in expansion of macro 'INFNAN_U8_NV_DECL' INFNAN_U8_NV_DECL PL_inf = { { LONGDBLINFBYTES } }; ^ ..\perl.h:5432:42: warning: excess elements in array initializer #define INFNAN_U8_NV_DECL EXTCONST union { U8 u8[NVSIZE]; NV nv; } ^ ------------- Now on VC C++ build, LONGDBLINFBYTES is 8 bytes, as defined in LONGDBLINFBYTES macro in config_H.vc, and for VC, "long double" is always typedefed by the CC to "double", so there was no warning, but on GCC, "long double" is the 80 bit/10 byte type and in config_H.gc the 12 byte version of INF is inside LONGDBLINFBYTES macro. Because LONG_DOUBLESIZE define was previously "8" because of makefile logic regardless of CC, # elif NVSIZE == LONG_DOUBLESIZE && defined(LONGDBLINFBYTES) INFNAN_U8_NV_DECL PL_inf = { { LONGDBLINFBYTES } }; was being hit on GCC, even though NVSIZE is 8 as it should be, but LONGDBLINFBYTES was 12. Hence the warning. I didnt research why this warning on GCC didn't cause test failures. Perhaps full perl recomputes the correct initializer in config_sh.PL and doesn't rely on what was in the miniperl initializer for PL_inf. To fix things, always emit the correct value for LONG_DOUBLESIZE and dont hardcode it at 8 for miniperl. 8 must stay for all VCs, and 12/16 is for GCC. Although GNUMakefile doesn't support a USE_CPLUSPLUS build option, it has provisons to support it one day. To keep things in sync, copy miniperl config.h append changes from makefile.mk to GNUMakefile. Also collapse 2 shell cmd lines in "ifeq ($(USE_LONG_DOUBLE),define)" to reduce number of proc launches of cmd.exe by the maketool (perf issue). Next C++ build issue. APItest.xs: In function 'void XS_XS__APItest__Backrefs_Comctl32Version(Perl Interpreter*, CV*)': APItest.xs:6806:37: error: cast from 'LPSTR {aka char*}' to 'WORD {aka shor t unsigned int}' loses precision [-fpermissive] MAKEINTRESOURCE(VS_FILE_INFO)); ^ dmake: Error code 129, while making 'APItest.o' VS_FILE_INFO is internally "RT_VERSION" which is MAKEINTRESOURCE(16). The output type of MAKEINTRESOURCE is a char *. GCC complains about casting that char * back down to a WORD (aka short). Put in a size_t used for pointer arithimitic to silence the error. Another option is to remove the outer MAKEINTRESOURCE in APItest.xs since RT_VERSION has MAKEINTRESOURCE internally, but that assumes implementation details of headers so pick the less dependency on header design option. --- ext/XS-APItest/APItest.pm | 2 +- ext/XS-APItest/APItest.xs | 2 +- win32/GNUmakefile | 23 +++++++++++++---------- win32/makefile.mk | 23 +++++++++++++---------- 4 files changed, 28 insertions(+), 22 deletions(-) diff --git a/ext/XS-APItest/APItest.pm b/ext/XS-APItest/APItest.pm index b98ccf8..07ff377 100644 --- a/ext/XS-APItest/APItest.pm +++ b/ext/XS-APItest/APItest.pm @@ -5,7 +5,7 @@ use strict; use warnings; use Carp; -our $VERSION = '0.97'; +our $VERSION = '0.98'; require XSLoader; diff --git a/ext/XS-APItest/APItest.xs b/ext/XS-APItest/APItest.xs index b9e9b09..f75ee94 100644 --- a/ext/XS-APItest/APItest.xs +++ b/ext/XS-APItest/APItest.xs @@ -6803,7 +6803,7 @@ Comctl32Version() if(!dll) croak("Comctl32Version: comctl32.dll not in process???"); hrsc = FindResource(dll, MAKEINTRESOURCE(VS_VERSION_INFO), - MAKEINTRESOURCE(VS_FILE_INFO)); + MAKEINTRESOURCE((Size_t)VS_FILE_INFO)); if(!hrsc) croak("Comctl32Version: comctl32.dll no version???"); ver = LoadResource(dll, hrsc); diff --git a/win32/GNUmakefile b/win32/GNUmakefile index c7b1316..0f67868 100644 --- a/win32/GNUmakefile +++ b/win32/GNUmakefile @@ -1336,6 +1336,11 @@ else echo #define Off_t_size ^4)>> config.h endif ifeq ($(WIN64),define) +ifeq ($(CCTYPE),GCC) + @(echo #define LONG_DOUBLESIZE ^16)>> config.h +else + @(echo #define LONG_DOUBLESIZE ^8)>> config.h +endif @(echo #define PTRSIZE ^8&& \ echo #define SSize_t $(INT64)&& \ echo #define HAS_ATOLL&& \ @@ -1343,6 +1348,11 @@ ifeq ($(WIN64),define) echo #define HAS_STRTOULL&& \ echo #define Size_t_size ^8)>> config.h else +ifeq ($(CCTYPE),GCC) + @(echo #define LONG_DOUBLESIZE ^12)>> config.h +else + @(echo #define LONG_DOUBLESIZE ^8)>> config.h +endif @(echo #define PTRSIZE ^4&& \ echo #define SSize_t int&& \ echo #undef HAS_ATOLL&& \ @@ -1394,15 +1404,9 @@ ifeq ($(USE_LONG_DOUBLE),define) echo #define PERL_PRIgldbl "Lg"&& \ echo #define PERL_PRIeldbl "Le"&& \ echo #define PERL_SCNfldbl "Lf"&& \ - echo #define NVTYPE long double)>> config.h -ifeq ($(WIN64),define) - @(echo #define NVSIZE ^16&& \ - echo #define LONG_DOUBLESIZE ^16)>> config.h -else - @(echo #define NVSIZE ^12&& \ - echo #define LONG_DOUBLESIZE ^12)>> config.h -endif - @(echo #define NV_OVERFLOWS_INTEGERS_AT 256.0*256.0*256.0*256.0*256.0*256.0*256.0*2.0*2.0*2.0*2.0*2.0*2.0*2.0*2.0&& \ + echo #define NVTYPE long double&& \ + echo #define NVSIZE LONG_DOUBLESIZE&& \ + echo #define NV_OVERFLOWS_INTEGERS_AT 256.0*256.0*256.0*256.0*256.0*256.0*256.0*2.0*2.0*2.0*2.0*2.0*2.0*2.0*2.0&& \ echo #define NVef "Le"&& \ echo #define NVff "Lf"&& \ echo #define NVgf "Lg"&& \ @@ -1421,7 +1425,6 @@ else echo #undef PERL_SCNfldbl&& \ echo #define NVTYPE double&& \ echo #define NVSIZE ^8&& \ - echo #define LONG_DOUBLESIZE ^8&& \ echo #define NV_OVERFLOWS_INTEGERS_AT 256.0*256.0*256.0*256.0*256.0*256.0*2.0*2.0*2.0*2.0*2.0&& \ echo #define NVef "e"&& \ echo #define NVff "f"&& \ diff --git a/win32/makefile.mk b/win32/makefile.mk index ca72535..0daeb79 100644 --- a/win32/makefile.mk +++ b/win32/makefile.mk @@ -1287,6 +1287,11 @@ $(MINIDIR)\.exists : $(CFGH_TMPL) echo #define Off_t_size ^4)>> config.h .ENDIF .IF "$(WIN64)"=="define" +.IF "$(CCTYPE)" == "GCC" + @(echo #define LONG_DOUBLESIZE ^16)>> config.h +.ELSE + @(echo #define LONG_DOUBLESIZE ^8)>> config.h +.ENDIF @(echo #define PTRSIZE ^8&& \ echo #define SSize_t $(INT64)&& \ echo #define HAS_ATOLL&& \ @@ -1294,6 +1299,11 @@ $(MINIDIR)\.exists : $(CFGH_TMPL) echo #define HAS_STRTOULL&& \ echo #define Size_t_size ^8)>> config.h .ELSE +.IF "$(CCTYPE)" == "GCC" + @(echo #define LONG_DOUBLESIZE ^12)>> config.h +.ELSE + @(echo #define LONG_DOUBLESIZE ^8)>> config.h +.ENDIF @(echo #define PTRSIZE ^4&& \ echo #define SSize_t int&& \ echo #undef HAS_ATOLL&& \ @@ -1345,15 +1355,9 @@ $(MINIDIR)\.exists : $(CFGH_TMPL) echo #define PERL_PRIgldbl "Lg"&& \ echo #define PERL_PRIeldbl "Le"&& \ echo #define PERL_SCNfldbl "Lf"&& \ - echo #define NVTYPE long double)>> config.h -.IF "$(WIN64)"=="define" - @(echo #define NVSIZE ^16&& \ - echo #define LONG_DOUBLESIZE ^16)>> config.h -.ELSE - @(echo #define NVSIZE ^12&& \ - echo #define LONG_DOUBLESIZE ^12)>> config.h -.ENDIF - @(echo #define NV_OVERFLOWS_INTEGERS_AT 256.0*256.0*256.0*256.0*256.0*256.0*256.0*2.0*2.0*2.0*2.0*2.0*2.0*2.0*2.0&& \ + echo #define NVTYPE long double&& \ + echo #define NVSIZE LONG_DOUBLESIZE&& \ + echo #define NV_OVERFLOWS_INTEGERS_AT 256.0*256.0*256.0*256.0*256.0*256.0*256.0*2.0*2.0*2.0*2.0*2.0*2.0*2.0*2.0&& \ echo #define NVef "Le"&& \ echo #define NVff "Lf"&& \ echo #define NVgf "Lg"&& \ @@ -1372,7 +1376,6 @@ $(MINIDIR)\.exists : $(CFGH_TMPL) echo #undef PERL_SCNfldbl&& \ echo #define NVTYPE double&& \ echo #define NVSIZE ^8&& \ - echo #define LONG_DOUBLESIZE ^8&& \ echo #define NV_OVERFLOWS_INTEGERS_AT 256.0*256.0*256.0*256.0*256.0*256.0*2.0*2.0*2.0*2.0*2.0&& \ echo #define NVef "e"&& \ echo #define NVff "f"&& \ -- 2.5.0.windows.1
To: Steve Hay <steve.m.hay [...] googlemail.com>
From: Dave Mitchell <davem [...] iabyn.com>
CC: Leon Timmermans <fawaka [...] gmail.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
Date: Wed, 25 Apr 2018 09:39:47 +0100
Download (untitled) / with headers
text/plain 823b
On Tue, Apr 24, 2018 at 05:23:25PM +0100, Steve Hay via perl5-porters wrote: Show quoted text
> On 24 April 2018 at 15:49, Dave Mitchell <davem@iabyn.com> wrote:
> > On Tue, Apr 24, 2018 at 02:56:00PM +0200, Leon Timmermans wrote: > >
> >> I would guess that making them EXTCONST again, but putting them inside > >> a START_EXTERN_C/END_EXTERN_C block would fix this.
> > > > That seems to work under linux. > > This branch I've just pushed, smoke-me/davem/nan_cpp, > > builds ok with gcc, g++ and clang on Linux. > > > > Does someone want to try it on Windows? > >
> > That fixes the problem for me.
I've now pushed that fix. I don't have an opinion about the Socket and Daniel issues. -- Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
On Tue, 24 Apr 2018 03:52:54 -0700, davem wrote: Show quoted text
> In more detail: > > before jhi's C++ fix, the declaration of PL_nan expanded to: > > extern const union { NV nv; U8 u8[8]; } PL_nan; > > and (under g++) gave this warning on the core *.c files: > > perl.h:6792:19: warning: unnamed type with no linkage used to declare > variable ‘const<unnamed union> PL_nan’ with linkage > > and this error on POSIX.i (when including perl.h): > > ../../perl.h:6792:19: error: ‘const<unnamed union> PL_nan’, declared > using unnamed type, is used but never defined [-fpermissive] > > jhi changed the declaration under C++ to expand to: > > extern "C" const union { NV nv; U8 u8[8]; } PL_nan; > > > and the warnings/errors went away on Linux, but broke Windows. > > Does anyone with knowledge about C++ and linking have any clue what > this > all means?
When I tried to write a cl-clang (visual c frontend for clang) perl port, I ran into a similar bug others caught at the time, that anonymous structs/unions aren't C++ portable. As I understand MS made anon types have a class name and therefore be extern, every other CC says that breaks C++ spec. See https://bugs.llvm.org/show_bug.cgi?id=24251 -- bulk88 ~ bulk88 at hotmail.com
To: Steve Hay <steve.m.hay [...] googlemail.com>
From: Leon Timmermans <fawaka [...] gmail.com>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: Dave Mitchell <davem [...] iabyn.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Date: Fri, 27 Apr 2018 15:56:15 +0200
Download (untitled) / with headers
text/plain 2.1k
On Tue, Apr 24, 2018 at 6:23 PM, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text
> On 24 April 2018 at 15:49, Dave Mitchell <davem@iabyn.com> wrote:
>> On Tue, Apr 24, 2018 at 02:56:00PM +0200, Leon Timmermans wrote: >>
>>> I would guess that making them EXTCONST again, but putting them inside >>> a START_EXTERN_C/END_EXTERN_C block would fix this.
>> >> That seems to work under linux. >> This branch I've just pushed, smoke-me/davem/nan_cpp, >> builds ok with gcc, g++ and clang on Linux. >> >> Does someone want to try it on Windows? >>
> > That fixes the problem for me. > > But I spoke to soon in claiming that the build otherwise worked with > VS2017. There is still one more problem: > > Socket.xs(804): error C2132: syntax error: unexpected identifier > Socket.xs(808): error C2132: syntax error: unexpected identifier > > I don't understand this one either. Line 804 is: > > if (sockaddr_len < STRUCT_OFFSET(struct sockaddr, sa_data)) > > which pre-processes to: > > if (sockaddr_len < __builtin_offsetof(struct sockaddr,sa_data)) > > Similar pre-processing happens in many other files and they compile > without trouble, e.g. in B.xs we have: > > { STR_WITH_LEN("next"), OPp, STRUCT_OFFSET(struct op, op_next), }, > > which becomes: > > { ("" "next" ""), (sizeof("next")-1), 0x3, > __builtin_offsetof(struct op,op_next), }, > > and causes no problem. > > I can't see why Socket is any different. However, It does contain this: > > /* STRUCT_OFFSET should have come from from perl.h, but if not, > * roll our own (not using offsetof() since that is C99). */ > #ifndef STRUCT_OFFSET > # define STRUCT_OFFSET(s,m) (Size_t)(&(((s *)0)->m)) > #endif > > and if I insert "#undef STRUCT_OFFSET" before that (to get rid of the > definition from perl.h and use the above instead) then it fixes it. > That can't be the right solution, though. > > *That* really is the last problem. With that hack in place the build > now succeeds.
Which version of VC++ is that? The visual studio forum seems to suggest there have been some issues in VS2017 but that they're resolved in the later releases. Does upgrading to the latest help? Leon
Date: Fri, 27 Apr 2018 18:28:42 +0100
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
CC: Dave Mitchell <davem [...] iabyn.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
To: Leon Timmermans <fawaka [...] gmail.com>
On 27 April 2018 at 14:56, Leon Timmermans <fawaka@gmail.com> wrote: Show quoted text
> On Tue, Apr 24, 2018 at 6:23 PM, Steve Hay <steve.m.hay@googlemail.com> wrote:
>> On 24 April 2018 at 15:49, Dave Mitchell <davem@iabyn.com> wrote:
>>> On Tue, Apr 24, 2018 at 02:56:00PM +0200, Leon Timmermans wrote: >>>
>>>> I would guess that making them EXTCONST again, but putting them inside >>>> a START_EXTERN_C/END_EXTERN_C block would fix this.
>>> >>> That seems to work under linux. >>> This branch I've just pushed, smoke-me/davem/nan_cpp, >>> builds ok with gcc, g++ and clang on Linux. >>> >>> Does someone want to try it on Windows? >>>
>> >> That fixes the problem for me. >> >> But I spoke to soon in claiming that the build otherwise worked with >> VS2017. There is still one more problem: >> >> Socket.xs(804): error C2132: syntax error: unexpected identifier >> Socket.xs(808): error C2132: syntax error: unexpected identifier >> >> I don't understand this one either. Line 804 is: >> >> if (sockaddr_len < STRUCT_OFFSET(struct sockaddr, sa_data)) >> >> which pre-processes to: >> >> if (sockaddr_len < __builtin_offsetof(struct sockaddr,sa_data)) >> >> Similar pre-processing happens in many other files and they compile >> without trouble, e.g. in B.xs we have: >> >> { STR_WITH_LEN("next"), OPp, STRUCT_OFFSET(struct op, op_next), }, >> >> which becomes: >> >> { ("" "next" ""), (sizeof("next")-1), 0x3, >> __builtin_offsetof(struct op,op_next), }, >> >> and causes no problem. >> >> I can't see why Socket is any different. However, It does contain this: >> >> /* STRUCT_OFFSET should have come from from perl.h, but if not, >> * roll our own (not using offsetof() since that is C99). */ >> #ifndef STRUCT_OFFSET >> # define STRUCT_OFFSET(s,m) (Size_t)(&(((s *)0)->m)) >> #endif >> >> and if I insert "#undef STRUCT_OFFSET" before that (to get rid of the >> definition from perl.h and use the above instead) then it fixes it. >> That can't be the right solution, though. >> >> *That* really is the last problem. With that hack in place the build >> now succeeds.
> > Which version of VC++ is that? The visual studio forum seems to > suggest there have been some issues in VS2017 but that they're > resolved in the later releases. Does upgrading to the latest help? > > Leon
That was VS2017 v15.4.2, cl.exe version 19.11.25547. I've now upgraded to VS2017 v15.6.7, cl.exe version 19.11.26132 and the errors are now more verbose :-) Socket.xs(804): error C2132: syntax error: unexpected identifier Socket.xs(804): note: offsetof has a builtin meaning; use /Zc:offsetof- to revert to old, non-conforming definition Socket.xs(808): error C2132: syntax error: unexpected identifier Socket.xs(808): note: offsetof has a builtin meaning; use /Zc:offsetof- to revert to old, non-conforming definition So now I see there is an obvious solution that I could employ (add /Zc:offsetof- to the compiler flags for this & later compilers), but I'm still puzzled exactly what the problem is and why it only affects Socket when there are so many other uses of STRUCT_OFFSET around the code.
Date: Sat, 28 Apr 2018 11:09:29 +0100
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: Leon Timmermans <fawaka [...] gmail.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
To: Steve Hay <steve.m.hay [...] googlemail.com>
Download (untitled) / with headers
text/plain 1.1k
On Fri, Apr 27, 2018 at 06:28:42PM +0100, Steve Hay via perl5-porters wrote: Show quoted text
> So now I see there is an obvious solution that I could employ (add > /Zc:offsetof- to the compiler flags for this & later compilers), but > I'm still puzzled exactly what the problem is and why it only affects > Socket when there are so many other uses of STRUCT_OFFSET around the > code.
Socket is the only non-core module (i.e. outside of ext/) which uses STRUCT_OFFSET. On unixy builds, cpan/ modules get passed a different set of compiler options than core code (generally less strict compiler warnings flags). Perhaps there's something similar for Windows builds? Commit v5.27.5-31-g346712be0b modified core to assume stddef.h and its features are always available. In particular it made this change to perl.h: -#if defined(STANDARD_C) && defined(I_STDDEF) && !defined(PERL_GCC_PEDANTIC) -# include <stddef.h> -# define STRUCT_OFFSET(s,m) offsetof(s,m) -#else -# define STRUCT_OFFSET(s,m) (Size_t)(&(((s *)0)->m)) -#endif +#include <stddef.h> +#define STRUCT_OFFSET(s,m) offsetof(s,m) Perhaps that chunk should be reverted for now? -- This is a great day for France! -- Nixon at Charles De Gaulle's funeral
To: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: Steve Hay <steve.m.hay [...] googlemail.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
From: Leon Timmermans <fawaka [...] gmail.com>
Date: Sat, 28 Apr 2018 13:38:49 +0200
Download (untitled) / with headers
text/plain 1.4k
On Sat, Apr 28, 2018 at 12:09 PM, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Fri, Apr 27, 2018 at 06:28:42PM +0100, Steve Hay via perl5-porters wrote:
>> So now I see there is an obvious solution that I could employ (add >> /Zc:offsetof- to the compiler flags for this & later compilers), but >> I'm still puzzled exactly what the problem is and why it only affects >> Socket when there are so many other uses of STRUCT_OFFSET around the >> code.
> > Socket is the only non-core module (i.e. outside of ext/) which uses > STRUCT_OFFSET. On unixy builds, cpan/ modules get passed a different > set of compiler options than core code (generally less strict compiler > warnings flags). Perhaps there's something similar for Windows builds? > > Commit v5.27.5-31-g346712be0b modified core to assume stddef.h and > its features are always available. In particular it made this change to > perl.h: > > > -#if defined(STANDARD_C) && defined(I_STDDEF) && !defined(PERL_GCC_PEDANTIC) > -# include <stddef.h> > -# define STRUCT_OFFSET(s,m) offsetof(s,m) > -#else > -# define STRUCT_OFFSET(s,m) (Size_t)(&(((s *)0)->m)) > -#endif > +#include <stddef.h> > +#define STRUCT_OFFSET(s,m) offsetof(s,m) > > Perhaps that chunk should be reverted for now?
Reverting it literally requires reverting more of Aaron's C89 work (I_STDDEF is eliminated and STANDARD_C mostly too). Just using the old definition here for VC++ may be the best solution for now. Leon
Date: Sat, 28 Apr 2018 12:59:42 +0100
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: Dave Mitchell <davem [...] iabyn.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
To: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 1.8k
On 28 April 2018 at 12:38, Leon Timmermans <fawaka@gmail.com> wrote: Show quoted text
> On Sat, Apr 28, 2018 at 12:09 PM, Dave Mitchell <davem@iabyn.com> wrote:
>> On Fri, Apr 27, 2018 at 06:28:42PM +0100, Steve Hay via perl5-porters wrote:
>>> So now I see there is an obvious solution that I could employ (add >>> /Zc:offsetof- to the compiler flags for this & later compilers), but >>> I'm still puzzled exactly what the problem is and why it only affects >>> Socket when there are so many other uses of STRUCT_OFFSET around the >>> code.
>> >> Socket is the only non-core module (i.e. outside of ext/) which uses >> STRUCT_OFFSET. On unixy builds, cpan/ modules get passed a different >> set of compiler options than core code (generally less strict compiler >> warnings flags). Perhaps there's something similar for Windows builds? >> >> Commit v5.27.5-31-g346712be0b modified core to assume stddef.h and >> its features are always available. In particular it made this change to >> perl.h: >> >> >> -#if defined(STANDARD_C) && defined(I_STDDEF) && !defined(PERL_GCC_PEDANTIC) >> -# include <stddef.h> >> -# define STRUCT_OFFSET(s,m) offsetof(s,m) >> -#else >> -# define STRUCT_OFFSET(s,m) (Size_t)(&(((s *)0)->m)) >> -#endif >> +#include <stddef.h> >> +#define STRUCT_OFFSET(s,m) offsetof(s,m) >> >> Perhaps that chunk should be reverted for now?
> > Reverting it literally requires reverting more of Aaron's C89 work > (I_STDDEF is eliminated and STANDARD_C mostly too). Just using the old > definition here for VC++ may be the best solution for now. >
Ok, that makes sense of it. The old definition only needs to be used for VS2017 onwards, though - the C++ build works fine right now with VS2015. I'll look into this later. (I don't think the other approach of using different compiler flags for cpan/ would be easy - it looks to me like cpan/, ext/ and dist/ all use the same flags on Windows.)
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: Dave Mitchell <davem [...] iabyn.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
To: Leon Timmermans <fawaka [...] gmail.com>
Date: Sat, 28 Apr 2018 15:12:58 +0100
Download (untitled) / with headers
text/plain 2.3k
On 28 April 2018 at 12:59, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text
> On 28 April 2018 at 12:38, Leon Timmermans <fawaka@gmail.com> wrote:
>> On Sat, Apr 28, 2018 at 12:09 PM, Dave Mitchell <davem@iabyn.com> wrote:
>>> On Fri, Apr 27, 2018 at 06:28:42PM +0100, Steve Hay via perl5-porters wrote:
>>>> So now I see there is an obvious solution that I could employ (add >>>> /Zc:offsetof- to the compiler flags for this & later compilers), but >>>> I'm still puzzled exactly what the problem is and why it only affects >>>> Socket when there are so many other uses of STRUCT_OFFSET around the >>>> code.
>>> >>> Socket is the only non-core module (i.e. outside of ext/) which uses >>> STRUCT_OFFSET. On unixy builds, cpan/ modules get passed a different >>> set of compiler options than core code (generally less strict compiler >>> warnings flags). Perhaps there's something similar for Windows builds? >>> >>> Commit v5.27.5-31-g346712be0b modified core to assume stddef.h and >>> its features are always available. In particular it made this change to >>> perl.h: >>> >>> >>> -#if defined(STANDARD_C) && defined(I_STDDEF) && !defined(PERL_GCC_PEDANTIC) >>> -# include <stddef.h> >>> -# define STRUCT_OFFSET(s,m) offsetof(s,m) >>> -#else >>> -# define STRUCT_OFFSET(s,m) (Size_t)(&(((s *)0)->m)) >>> -#endif >>> +#include <stddef.h> >>> +#define STRUCT_OFFSET(s,m) offsetof(s,m) >>> >>> Perhaps that chunk should be reverted for now?
>> >> Reverting it literally requires reverting more of Aaron's C89 work >> (I_STDDEF is eliminated and STANDARD_C mostly too). Just using the old >> definition here for VC++ may be the best solution for now. >>
> > Ok, that makes sense of it. > > The old definition only needs to be used for VS2017 onwards, though - > the C++ build works fine right now with VS2015. I'll look into this > later. (I don't think the other approach of using different compiler > flags for cpan/ would be easy - it looks to me like cpan/, ext/ and > dist/ all use the same flags on Windows.)
Now in blead in commit 4bd4e9335ffc257cbe2bf1a42789f693f5797337. (Actually, I'm still confused why Socket failed given that Windows doesn't compile cpan/ differently to dist/ and ext/, but I've spent too long staring at this now...) That just leaves the GCC fixes from bulk88 to deal with on this ticket. I'll look at them soon if nobody else gets there first.
To: Steve Hay <steve.m.hay [...] googlemail.com>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: Leon Timmermans <fawaka [...] gmail.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
From: Dave Mitchell <davem [...] iabyn.com>
Date: Thu, 10 May 2018 10:29:52 +0100
Download (untitled) / with headers
text/plain 612b
On Sat, Apr 28, 2018 at 03:12:58PM +0100, Steve Hay via perl5-porters wrote: Show quoted text
> Now in blead in commit 4bd4e9335ffc257cbe2bf1a42789f693f5797337. > > (Actually, I'm still confused why Socket failed given that Windows > doesn't compile cpan/ differently to dist/ and ext/, but I've spent > too long staring at this now...) > > That just leaves the GCC fixes from bulk88 to deal with on this > ticket. I'll look at them soon if nobody else gets there first.
Are tou likely to be able to look at these? -- Red sky at night - gerroff my land! Red sky at morning - gerroff my land! -- old farmers' sayings #14
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
CC: Leon Timmermans <fawaka [...] gmail.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
To: Dave Mitchell <davem [...] iabyn.com>
Date: Thu, 10 May 2018 14:01:48 +0100
Download (untitled) / with headers
text/plain 780b
On 10 May 2018 at 10:29, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Sat, Apr 28, 2018 at 03:12:58PM +0100, Steve Hay via perl5-porters wrote:
>> Now in blead in commit 4bd4e9335ffc257cbe2bf1a42789f693f5797337. >> >> (Actually, I'm still confused why Socket failed given that Windows >> doesn't compile cpan/ differently to dist/ and ext/, but I've spent >> too long staring at this now...) >> >> That just leaves the GCC fixes from bulk88 to deal with on this >> ticket. I'll look at them soon if nobody else gets there first.
> > Are tou likely to be able to look at these? >
Yes, I will do. Sorry for the delay. Not even being able to build in normal C mode with recent mingw.org compilers (RT#128631) hasn't helped, but I will go back to mingw-w64 compilers for these fixes.
To: Steve Hay <steve.m.hay [...] googlemail.com>
From: Aaron Crane <arc [...] cpan.org>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: Leon Timmermans <fawaka [...] gmail.com>, Dave Mitchell <davem [...] iabyn.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Date: Thu, 10 May 2018 14:33:13 +0100
Download (untitled) / with headers
text/plain 570b
Steve Hay via perl5-porters <perl5-porters@perl.org> wrote: Show quoted text
> (Actually, I'm still confused why Socket failed given that Windows > doesn't compile cpan/ differently to dist/ and ext/, but I've spent > too long staring at this now...)
C++ restricts use of offsetof() to (roughly speaking) the C-like subset of struct/class types. Do the headers in VS2017 have different definitions of struct sockaddr for C and C++ builds, with C++-specific features where available? That could explain why only this use of offsetof() on only this compiler is affected. -- Aaron Crane
Date: Mon, 14 May 2018 18:03:02 +0100
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
CC: Leon Timmermans <fawaka [...] gmail.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
To: Dave Mitchell <davem [...] iabyn.com>
Download (untitled) / with headers
text/plain 3.5k
On 10 May 2018 at 14:01, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text
> On 10 May 2018 at 10:29, Dave Mitchell <davem@iabyn.com> wrote:
>> On Sat, Apr 28, 2018 at 03:12:58PM +0100, Steve Hay via perl5-porters wrote:
>>> Now in blead in commit 4bd4e9335ffc257cbe2bf1a42789f693f5797337. >>> >>> (Actually, I'm still confused why Socket failed given that Windows >>> doesn't compile cpan/ differently to dist/ and ext/, but I've spent >>> too long staring at this now...) >>> >>> That just leaves the GCC fixes from bulk88 to deal with on this >>> ticket. I'll look at them soon if nobody else gets there first.
>> >> Are tou likely to be able to look at these? >>
> > Yes, I will do. Sorry for the delay. Not even being able to build in > normal C mode with recent mingw.org compilers (RT#128631) hasn't > helped, but I will go back to mingw-w64 compilers for these fixes.
Finally tried this out, using MinGW-w64 compilers (6.3.0 and 7.1.0). I tried x86 versions with and without USE_CPLUSPLUS and all is well. (I thought MinGW 4.8.1 would work as well, but it has trouble with fstat calls and is only happy in normal C mode - see perl #128631. I'm not going to worry about that...) I noticed that config_sh.PL corrects longdblsize (and uses it for nvsize) - exactly as per the logic in the makefiles (for the miniperl build) with this patch, which gives confidence that it's correct. unless ($opt{cc} =~ /\bcl/) { if ($opt{WIN64} eq 'define') { $opt{longdblsize} = 16; $opt{longdblinfbytes} = '0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0xff, 0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00'; $opt{longdblnanbytes} = '0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00'; } else { $opt{longdblsize} = 12; $opt{longdblinfbytes} = '0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0xff, 0x7f, 0x00, 0x00'; $opt{longdblnanbytes} = '0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xff, 0xff, 0x00, 0x00'; } } One minor thing, though: config_sh.PL also adjusts longdblinfbytes and longdblnanbytes (16- or 12- bytes versions). Is it worth also doing this in the makefiles, or maybe it's not really relevant for miniperl anyway since it's only really used to complete the build and nothing else)? The other thing I noticed is that lib/ExtUtils/t/Embed.t fails in the C++ builds, but works fine in C builds. However, when I tried the x64 compilers, it didn't go so well :-( The build still fails in C++ mode (with both 6.3.0 and 7.1.0, both from MinGW-w64): gcc -c -xc++ -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv -fno-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"3.40\" -DXS_VERSION=\"3.40\" "-I..\..\lib\CORE" RealPPPort.c In file included from RealPPPort.xs:31:0: RealPPPort.xs: In function 'void XS_Devel__PPPort_ptrtests(PerlInterpreter*, CV*)': ..\..\lib\CORE/perl.h:1739:33: error: cast from 'int*' to 'long unsigned int' loses precision [-fpermissive] # define INT2PTR(any,d) (any)(d) ^ ..\..\lib\CORE/perl.h:1752:21: note: in expansion of macro 'INT2PTR' # define PTR2ul(p) INT2PTR(unsigned long,p) ^~~~~~~ RealPPPort.xs:1650:27: note: in expansion of macro 'PTR2ul' RETVAL += PTR2ul(p) != 0UL ? 2 : 0; ^ dmake: Error code 129, while making 'RealPPPort.o' Unsuccessful make(dist/Devel-PPPort): code=65280 at ..\make_ext.pl line 570. dmake: Error code 130, while making 'Extensions'
To: Steve Hay <steve.m.hay [...] googlemail.com>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: Leon Timmermans <fawaka [...] gmail.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
From: Dave Mitchell <davem [...] iabyn.com>
Date: Tue, 22 May 2018 09:55:30 +0100
Download (untitled) / with headers
text/plain 1.4k
On Mon, May 14, 2018 at 06:03:02PM +0100, Steve Hay via perl5-porters wrote: Show quoted text
> On 10 May 2018 at 14:01, Steve Hay <steve.m.hay@googlemail.com> wrote:
> > On 10 May 2018 at 10:29, Dave Mitchell <davem@iabyn.com> wrote:
> >> On Sat, Apr 28, 2018 at 03:12:58PM +0100, Steve Hay via perl5-porters wrote:
> >>> Now in blead in commit 4bd4e9335ffc257cbe2bf1a42789f693f5797337. > >>> > >>> (Actually, I'm still confused why Socket failed given that Windows > >>> doesn't compile cpan/ differently to dist/ and ext/, but I've spent > >>> too long staring at this now...) > >>> > >>> That just leaves the GCC fixes from bulk88 to deal with on this > >>> ticket. I'll look at them soon if nobody else gets there first.
> >> > >> Are tou likely to be able to look at these? > >>
> > > > Yes, I will do. Sorry for the delay. Not even being able to build in > > normal C mode with recent mingw.org compilers (RT#128631) hasn't > > helped, but I will go back to mingw-w64 compilers for these fixes.
> > Finally tried this out, using MinGW-w64 compilers (6.3.0 and 7.1.0). I > tried x86 versions with and without USE_CPLUSPLUS and all is well. (I > thought MinGW 4.8.1 would work as well, but it has trouble with fstat > calls and is only happy in normal C mode - see perl #128631. I'm not > going to worry about that...)
Should this work so far be applied in time for an -RC2? -- Dave's first rule of Opera: If something needs saying, say it: don't warble it.
To: Dave Mitchell <davem [...] iabyn.com>
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
CC: Leon Timmermans <fawaka [...] gmail.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Date: Tue, 22 May 2018 17:52:58 +0100
Download (untitled) / with headers
text/plain 1.9k
On 22 May 2018 at 09:55, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Mon, May 14, 2018 at 06:03:02PM +0100, Steve Hay via perl5-porters wrote:
>> On 10 May 2018 at 14:01, Steve Hay <steve.m.hay@googlemail.com> wrote:
>> > On 10 May 2018 at 10:29, Dave Mitchell <davem@iabyn.com> wrote:
>> >> On Sat, Apr 28, 2018 at 03:12:58PM +0100, Steve Hay via perl5-porters wrote:
>> >>> Now in blead in commit 4bd4e9335ffc257cbe2bf1a42789f693f5797337. >> >>> >> >>> (Actually, I'm still confused why Socket failed given that Windows >> >>> doesn't compile cpan/ differently to dist/ and ext/, but I've spent >> >>> too long staring at this now...) >> >>> >> >>> That just leaves the GCC fixes from bulk88 to deal with on this >> >>> ticket. I'll look at them soon if nobody else gets there first.
>> >> >> >> Are tou likely to be able to look at these? >> >>
>> > >> > Yes, I will do. Sorry for the delay. Not even being able to build in >> > normal C mode with recent mingw.org compilers (RT#128631) hasn't >> > helped, but I will go back to mingw-w64 compilers for these fixes.
>> >> Finally tried this out, using MinGW-w64 compilers (6.3.0 and 7.1.0). I >> tried x86 versions with and without USE_CPLUSPLUS and all is well. (I >> thought MinGW 4.8.1 would work as well, but it has trouble with fstat >> calls and is only happy in normal C mode - see perl #128631. I'm not >> going to worry about that...)
> > Should this work so far be applied in time for an -RC2? >
Yes, I think so. It's not complete, but it's an improvement on the current situation. If the remaining problems don't get fixed in time then I guess the failures will just have to be documented, as I'm already (still) intending to do for the failing mingw.org compilers (see #128631). I don't think the C++ build trouble is a showstopper anyway. Most people probably don't use it other than as a means to check the build with different compiler options (it generally throws up more warnings and/or turns previously overlooked warnings into errors).
Date: Thu, 24 May 2018 13:42:02 +0100
To: Dave Mitchell <davem [...] iabyn.com>
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
CC: Leon Timmermans <fawaka [...] gmail.com>, Steve Hay via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
Download (untitled) / with headers
text/plain 2.4k
On 22 May 2018 at 17:52, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text
> On 22 May 2018 at 09:55, Dave Mitchell <davem@iabyn.com> wrote:
>> On Mon, May 14, 2018 at 06:03:02PM +0100, Steve Hay via perl5-porters wrote:
>>> On 10 May 2018 at 14:01, Steve Hay <steve.m.hay@googlemail.com> wrote:
>>> > On 10 May 2018 at 10:29, Dave Mitchell <davem@iabyn.com> wrote:
>>> >> On Sat, Apr 28, 2018 at 03:12:58PM +0100, Steve Hay via perl5-porters wrote:
>>> >>> Now in blead in commit 4bd4e9335ffc257cbe2bf1a42789f693f5797337. >>> >>> >>> >>> (Actually, I'm still confused why Socket failed given that Windows >>> >>> doesn't compile cpan/ differently to dist/ and ext/, but I've spent >>> >>> too long staring at this now...) >>> >>> >>> >>> That just leaves the GCC fixes from bulk88 to deal with on this >>> >>> ticket. I'll look at them soon if nobody else gets there first.
>>> >> >>> >> Are tou likely to be able to look at these? >>> >>
>>> > >>> > Yes, I will do. Sorry for the delay. Not even being able to build in >>> > normal C mode with recent mingw.org compilers (RT#128631) hasn't >>> > helped, but I will go back to mingw-w64 compilers for these fixes.
>>> >>> Finally tried this out, using MinGW-w64 compilers (6.3.0 and 7.1.0). I >>> tried x86 versions with and without USE_CPLUSPLUS and all is well. (I >>> thought MinGW 4.8.1 would work as well, but it has trouble with fstat >>> calls and is only happy in normal C mode - see perl #128631. I'm not >>> going to worry about that...)
>> >> Should this work so far be applied in time for an -RC2? >>
> > Yes, I think so. It's not complete, but it's an improvement on the > current situation. If the remaining problems don't get fixed in time > then I guess the failures will just have to be documented, as I'm > already (still) intending to do for the failing mingw.org compilers > (see #128631). > > I don't think the C++ build trouble is a showstopper anyway. Most > people probably don't use it other than as a means to check the build > with different compiler options (it generally throws up more warnings > and/or turns previously overlooked warnings into errors).
I've now pushed the main patch here in commit a385474c9667eb0a1b5fbba5f817d90686929349. The remaining problems (along with those reported on #128631) are also now documented (in commit 8a217c9aa73da6153273a3bfa4c89fa15e95587b), but I think we can probably remove this ticket from the blockers list now. I will do that in the next couple of days unless anyone objects.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.7k
On Thu, 24 May 2018 05:42:29 -0700, shay wrote: Show quoted text
> On 22 May 2018 at 17:52, Steve Hay <steve.m.hay@googlemail.com> wrote:
> > On 22 May 2018 at 09:55, Dave Mitchell <davem@iabyn.com> wrote:
> >> On Mon, May 14, 2018 at 06:03:02PM +0100, Steve Hay via perl5- > >> porters wrote:
> >>> On 10 May 2018 at 14:01, Steve Hay <steve.m.hay@googlemail.com> > >>> wrote:
> >>> > On 10 May 2018 at 10:29, Dave Mitchell <davem@iabyn.com> wrote:
> >>> >> On Sat, Apr 28, 2018 at 03:12:58PM +0100, Steve Hay via perl5- > >>> >> porters wrote:
> >>> >>> Now in blead in commit > >>> >>> 4bd4e9335ffc257cbe2bf1a42789f693f5797337. > >>> >>> > >>> >>> (Actually, I'm still confused why Socket failed given that > >>> >>> Windows > >>> >>> doesn't compile cpan/ differently to dist/ and ext/, but I've > >>> >>> spent > >>> >>> too long staring at this now...) > >>> >>> > >>> >>> That just leaves the GCC fixes from bulk88 to deal with on this > >>> >>> ticket. I'll look at them soon if nobody else gets there first.
> >>> >> > >>> >> Are tou likely to be able to look at these? > >>> >>
> >>> > > >>> > Yes, I will do. Sorry for the delay. Not even being able to build > >>> > in > >>> > normal C mode with recent mingw.org compilers (RT#128631) hasn't > >>> > helped, but I will go back to mingw-w64 compilers for these > >>> > fixes.
> >>> > >>> Finally tried this out, using MinGW-w64 compilers (6.3.0 and > >>> 7.1.0). I > >>> tried x86 versions with and without USE_CPLUSPLUS and all is well. > >>> (I > >>> thought MinGW 4.8.1 would work as well, but it has trouble with > >>> fstat > >>> calls and is only happy in normal C mode - see perl #128631. I'm > >>> not > >>> going to worry about that...)
> >> > >> Should this work so far be applied in time for an -RC2? > >>
> > > > Yes, I think so. It's not complete, but it's an improvement on the > > current situation. If the remaining problems don't get fixed in time > > then I guess the failures will just have to be documented, as I'm > > already (still) intending to do for the failing mingw.org compilers > > (see #128631). > > > > I don't think the C++ build trouble is a showstopper anyway. Most > > people probably don't use it other than as a means to check the build > > with different compiler options (it generally throws up more warnings > > and/or turns previously overlooked warnings into errors).
> > I've now pushed the main patch here in commit > a385474c9667eb0a1b5fbba5f817d90686929349. The remaining problems > (along with those reported on #128631) are also now documented (in > commit 8a217c9aa73da6153273a3bfa4c89fa15e95587b), but I think we can > probably remove this ticket from the blockers list now. > > I will do that in the next couple of days unless anyone objects.
Now removed from blockers list.


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