Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables #16459

Open
p5pRT opened this issue Mar 8, 2018 · 50 comments
Open

USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables #16459

p5pRT opened this issue Mar 8, 2018 · 50 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Mar 8, 2018

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

Searchable as RT132955$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 8, 2018

From @bulk88

Created by @bulk88

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.

Perl Info

Flags:
          category=core
          severity=low

Site configuration information for perl 5.27.9:

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

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

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



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


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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 13, 2018

From @steve-m-hay

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 13, 2018

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 13, 2018

From @khwilliamson

On 04/13/2018 02​:20 AM, Steve Hay via perl5-porters wrote​:

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 13, 2018

From @khwilliamson

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 13, 2018

From @khwilliamson

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 13, 2018

From @steve-m-hay

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
d3a5b29
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 d3a5b29,
which I'd updated to in the hope that it might fix the build since I'd
previously tried with the previous commit
(1b30b4a), 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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 13, 2018

From @Leont

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
d3a5b29
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 d3a5b29,
which I'd updated to in the hope that it might fix the build since I'd
previously tried with the previous commit
(1b30b4a), 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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 13, 2018

From @jkeenan

On 04/13/2018 11​:36 AM, Leon Timmermans wrote​:

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
d3a5b29
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 d3a5b29,
which I'd updated to in the hope that it might fix the build since I'd
previously tried with the previous commit
(1b30b4a), 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 d3a5b29​:

#####

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 13, 2018

From @Leont

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 13, 2018

From @Leont

0001-Make-vutil.c-C-11-compatible.patch
From 45c7b15ce30aa88f34a3a85a9fa900a4fb61c92c Mon Sep 17 00:00:00 2001
From: Leon Timmermans <fawaka@gmail.com>
Date: Sat, 14 Apr 2018 00:32:49 +0200
Subject: [PATCH] Make vutil.c C++11 compatible

---
 vutil.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/vutil.c b/vutil.c
index a3f11bee60..97eecebe36 100644
--- a/vutil.c
+++ b/vutil.c
@@ -693,12 +693,12 @@ VER_NV:
 #endif
 
 	if (sv) {
-	    Perl_sv_catpvf(aTHX_ sv, "%.9"NVff, SvNVX(ver));
+	    Perl_sv_catpvf(aTHX_ sv, "%.9" NVff, SvNVX(ver));
 	    len = SvCUR(sv);
 	    buf = SvPVX(sv);
 	}
 	else {
-	    len = my_snprintf(tbuf, sizeof(tbuf), "%.9"NVff, SvNVX(ver));
+	    len = my_snprintf(tbuf, sizeof(tbuf), "%.9" NVff, SvNVX(ver));
 	    buf = tbuf;
 	}
 
@@ -989,11 +989,11 @@ Perl_vnormal(pTHX_ SV *vs)
 	SV * tsv = *av_fetch(av, 0, 0);
 	digit = SvIV(tsv);
     }
-    sv = Perl_newSVpvf(aTHX_ "v%"IVdf, (IV)digit);
+    sv = Perl_newSVpvf(aTHX_ "v%" IVdf, (IV)digit);
     for ( i = 1 ; i <= len ; i++ ) {
 	SV * tsv = *av_fetch(av, i, 0);
 	digit = SvIV(tsv);
-	Perl_sv_catpvf(aTHX_ sv, ".%"IVdf, (IV)digit);
+	Perl_sv_catpvf(aTHX_ sv, ".%" IVdf, (IV)digit);
     }
 
     if ( len <= 2 ) { /* short version, must be at least three */
-- 
2.16.2

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 14, 2018

From @khwilliamson

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
d3a5b29
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 d3a5b29,
which I'd updated to in the hope that it might fix the build since I'd
previously tried with the previous commit
(1b30b4a), 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?

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 14, 2018

From @steve-m-hay

On 14 April 2018 at 05​:01, Karl Williamson <public@​khwilliamson.com> wrote​:

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
d3a5b29
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 d3a5b29,
which I'd updated to in the hope that it might fix the build since I'd
previously tried with the previous commit
(1b30b4a), 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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 14, 2018

From @khwilliamson

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 16, 2018

From @jkeenan

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 19, 2018

From @xsawyerx

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 19, 2018

From @steve-m-hay

On 19 April 2018 at 17​:17, Sawyer X via RT <perlbug-followup@​perl.org> wrote​:

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 19, 2018

From @Leont

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?

Leon

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 19, 2018

From @Leont

0001-Make-PERLIO_FILE_file-an-lvalue.patch
From 0387c9e60162597aba955cf7e715d85ca12d11ea Mon Sep 17 00:00:00 2001
From: Leon Timmermans <fawaka@gmail.com>
Date: Thu, 19 Apr 2018 19:05:35 +0200
Subject: [PATCH] Make PERLIO_FILE_file() an lvalue

---
 win32/win32.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/win32/win32.h b/win32/win32.h
index 29621c0cd3..d514c3653d 100644
--- a/win32/win32.h
+++ b/win32/win32.h
@@ -344,7 +344,7 @@ typedef struct
 #define PERLIO_FILE_base(f) (((__crt_stdio_stream_data*)(f))->_base)
 #define PERLIO_FILE_cnt(f)  (((__crt_stdio_stream_data*)(f))->_cnt)
 #define PERLIO_FILE_flag(f) ((int)(((__crt_stdio_stream_data*)(f))->_flags))
-#define PERLIO_FILE_file(f) ((int)(((__crt_stdio_stream_data*)(f))->_file))
+#define PERLIO_FILE_file(f) (*(int*)(&((__crt_stdio_stream_data*)(f))->_file))
 
 #endif
 
-- 
2.16.2

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 20, 2018

From @bulk88

On Thu, 19 Apr 2018 09​:17​:31 -0700, xsawyerx@​cpan.org wrote​:

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

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 21, 2018

From @bulk88

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?

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 23, 2018

From @steve-m-hay

On Thu, 19 Apr 2018 10​:34​:04 -0700, LeonT wrote​:

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 002a841.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 23, 2018

From @steve-m-hay

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 23, 2018

From @iabyn

On Mon, Apr 23, 2018 at 05​:59​:21AM -0700, Steve Hay via RT wrote​:

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 23, 2018

From @iabyn

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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 24, 2018

From @iabyn

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?

--
"You're so sadly neglected, and often ignored.
A poor second to Belgium, When going abroad."
  -- Monty Python, "Finland"

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 24, 2018

From @Leont

On Tue, Apr 24, 2018 at 12​:52 PM, Dave Mitchell <davem@​iabyn.com> wrote​:

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&#8203;:6792&#8203;:19&#8203;: warning&#8203;: 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&#8203;:6792&#8203;:19&#8203;: error&#8203;: ‘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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 24, 2018

From @iabyn

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?

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 24, 2018

From @steve-m-hay

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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 24, 2018

From @bulk88

On Tue, 24 Apr 2018 09​:23​:38 -0700, shay wrote​:

*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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 24, 2018

From @bulk88

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 25, 2018

From @iabyn

On Tue, Apr 24, 2018 at 05​:23​:25PM +0100, Steve Hay via perl5-porters 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.

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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 27, 2018

From @bulk88

On Tue, 24 Apr 2018 03​:52​:54 -0700, davem wrote​:

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 27, 2018

From @Leont

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 27, 2018

From @steve-m-hay

On 27 April 2018 at 14​:56, Leon Timmermans <fawaka@​gmail.com> wrote​:

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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 28, 2018

From @iabyn

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?

--
This is a great day for France!
  -- Nixon at Charles De Gaulle's funeral

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 28, 2018

From @Leont

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.

Leon

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 28, 2018

From @steve-m-hay

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 28, 2018

From @steve-m-hay

On 28 April 2018 at 12​:59, Steve Hay <steve.m.hay@​googlemail.com> wrote​:

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 4bd4e93.

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 10, 2018

From @iabyn

On Sat, Apr 28, 2018 at 03​:12​:58PM +0100, Steve Hay via perl5-porters wrote​:

Now in blead in commit 4bd4e93.

(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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 10, 2018

From @steve-m-hay

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 4bd4e93.

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 10, 2018

From @arc

Steve Hay via perl5-porters <perl5-porters@​perl.org> wrote​:

(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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 14, 2018

From @steve-m-hay

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 4bd4e93.

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 22, 2018

From @iabyn

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 4bd4e93.

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 22, 2018

From @steve-m-hay

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 4bd4e93.

(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).

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 24, 2018

From @steve-m-hay

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 4bd4e93.

(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
a385474. The remaining problems
(along with those reported on #128631) are also now documented (in
commit 8a217c9), 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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 30, 2018

From @steve-m-hay

On Thu, 24 May 2018 05​:42​:29 -0700, shay wrote​:

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
4bd4e93.

(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
a385474. The remaining problems
(along with those reported on #128631) are also now documented (in
commit 8a217c9), 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.

@khwilliamson
Copy link
Contributor

@khwilliamson khwilliamson commented Apr 17, 2022

Is this now fixed?

@jkeenan
Copy link
Contributor

@jkeenan jkeenan commented Apr 17, 2022

Is this now fixed?

@steve-m-hay, can you provide an update for this ticket?

@steve-m-hay
Copy link
Contributor

@steve-m-hay steve-m-hay commented May 5, 2022

Is this now fixed?

@steve-m-hay, can you provide an update for this ticket?

(Apologies for the slow reply. GitHub doesn't email me when I get a mention in anything, so I miss them until I happen to log in.)

The C++ build is still broken - very early in the build. It only gets as far as sv.c:

E:\Dev\Git\perl\win32>nmake CCTYPE=MSVC142 USE_CPLUSPLUS=define
[...]
cl -c -nologo -GF -W3 -MD -TP -EHsc -I..\lib\CORE -I.\include -I. -I.. -DWIN32 -D_CONSOLE -DNO_STRICT -DWIN64 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS -DPERLDLL -DPERL_CORE -O1 -Zi -GL -fp:precise -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -Fo.\mini\sv.obj ..\sv.c
sv.c
E:\Dev\Git\perl\inline.h(2827): warning C4244: '=': conversion from '__int64' to 'I32', possible loss of data
E:\Dev\Git\perl\inline.h(2902): warning C4244: '=': conversion from '__int64' to 'I32', possible loss of data
E:\Dev\Git\perl\inline.h(2963): warning C4244: '=': conversion from '__int64' to 'I32', possible loss of data
..\sv.c(1062): error C7555: use of designated initializers requires at least '/std:c++latest'
..\sv.c(1062): error C7555: use of designated initializers requires at least '/std:c++latest'
..\sv.c(1064): error C4576: a parenthesized type followed by an initializer list is a non-standard explicit type conversion syntax
..\sv.c(1069): error C7555: use of designated initializers requires at least '/std:c++latest'
..\sv.c(1069): error C7555: use of designated initializers requires at least '/std:c++latest'
..\sv.c(1073): error C4576: a parenthesized type followed by an initializer list is a non-standard explicit type conversion syntax
..\sv.c(3600): warning C4244: 'initializing': conversion from '__int64' to 'I32', possible loss of data
..\sv.c(3603): warning C4804: '-': unsafe use of type 'bool' in operation
..\sv.c(3678): warning C4267: 'argument': conversion from 'size_t' to 'U32', possible loss of data
..\sv.c(3948): warning C4244: 'initializing': conversion from '__int64' to 'I32', possible loss of data
..\sv.c(3973): warning C4244: 'argument': conversion from '__int64' to 'const I32', possible loss of data
..\sv.c(4576): warning C4244: 'argument': conversion from 'const __int64' to 'const I32', possible loss of data
..\sv.c(8726): warning C4267: '=': conversion from 'size_t' to 'I32', possible loss of data
..\sv.c(9565): warning C4267: '=': conversion from 'size_t' to 'I32', possible loss of data
..\sv.c(9596): warning C4267: 'argument': conversion from 'size_t' to 'I32', possible loss of data
..\sv.c(9857): warning C4267: 'initializing': conversion from 'size_t' to 'U32', possible loss of data
..\sv.c(9857): warning C4267: 'initializing': conversion from 'size_t' to 'const U32', possible loss of data
..\sv.c(13206): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
..\sv.c(13211): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
..\sv.c(16184): warning C4244: '=': conversion from 'IV' to 'int', possible loss of data
..\sv.c(16225): warning C4267: '=': conversion from 'size_t' to 'I32', possible loss of data
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\bin\HostX64\x64\cl.EXE"' : return code '0x2'
Stop.

(Ignore all the warnings - they're sadly normal when building on Windows, at least in 64-bit.)

This is current blead (5a1627d) with Visual Studio 2019 Community v14.28.29910 x64.

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

No branches or pull requests

5 participants