USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables #16459
Comments
From @bulk88Created by @bulk885.26 (maint-5.26) and 5.27 blead both fail with Win32 VC perl compiled -------------------------------------- I traced the failure to plain C (works) vs C++ (broken) POSIX.i diff -extern __declspec(dllimport) const union { NV nv; U8 u8[8]; } PL_inf; #line 6766 "..\\..\\lib\\CORE\\perl.h" --------------------------------------------- So the var isn't declared as crossing DLL boundaries. So it doesnt, and https://perl5.git.perl.org/perl.git/commitdiff/0879cd66ef3f00918ae26d9bb7ac555d3911c548 The 5.26 Win32 binary (perl526.dll) DOES export PL_nan and PL_inf A 2nd less correct way of fixing it, is eliminating the use of global --------------------------------- 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 \ which uses PL_nan directly without the "platform specific" NV_NAN Perl Info |
From @steve-m-hayOn 8 March 2018 at 15:57, bulk88 <perlbug-followup@perl.org> wrote:
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.. (All these versions of VC work fine without USE_CPLUSPLUS=define.) |
|
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn 04/13/2018 02:20 AM, Steve Hay via perl5-porters wrote:
What was the latest commit in blead that this was this run on? The
|
From @khwilliamsonOn 04/13/2018 08:57 AM, Karl Williamson wrote:
Actually, to save email back-and-forths, if you ran it on the very |
From @khwilliamsonOn 04/13/2018 09:05 AM, Karl Williamson wrote:
And so, if you run it on blead just prior to that commit, we could see |
From @steve-m-hayOn 13 April 2018 at 16:21, Karl Williamson <public@khwilliamson.com> wrote:
The result I reported was on d3a5b29, cl -c -nologo -GF -W3 -TP -EHsc -I..\lib\CORE -I.\include -I. -I.. |
From @LeontOn Fri, Apr 13, 2018 at 5:24 PM, Steve Hay via perl5-porters
literal operators are a C++11-ism. Adding spaces between a literal Leon |
From @jkeenanOn 04/13/2018 11:36 AM, Leon Timmermans wrote:
This may relate to part of the synching I performed yesterday. Consider ##### Inline Patchdiff --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 If that is so, then what should probably happen is: (a) revert the diff Let me know if you need further assistance. Thank you very much. |
From @LeontOn Fri, Apr 13, 2018 at 9:13 PM, James E Keenan <jkeenan@pobox.com> wrote:
I believe the attached patch will fix that issue, but I haven't tested Leon |
From @Leont0001-Make-vutil.c-C-11-compatible.patchFrom 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
|
From @khwilliamsonOn 04/13/2018 09:24 AM, Steve Hay wrote:
Could you please try it on the branch smoke-me/khw-shay and post any |
From @steve-m-hayOn 14 April 2018 at 05:01, Karl Williamson <public@khwilliamson.com> wrote:
On that branch, both universal.c and util.c now compile but now we run cl -c -nologo -GF -W3 -TP -EHsc -I..\lib\CORE -I.\include -I. -I.. I obviously haven't tried a C++ build with VS2015 since adding support 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 Thanks. |
From @khwilliamsonOn 04/13/2018 04:34 PM, Leon Timmermans wrote:
Yes, the issue is a result of the cpan overwrite of what is in blead. The problem, which I alluded to in my post, is that vutil.c lost some |
From @jkeenanOn Sat, 14 Apr 2018 16:39:11 GMT, public@khwilliamson.com wrote:
(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 |
From @xsawyerxOn Sun, 15 Apr 2018 18:24:06 -0700, jkeenan wrote:
So should this be resolved? |
From @steve-m-hayOn 19 April 2018 at 17:17, Sawyer X via RT <perlbug-followup@perl.org> wrote:
Not yet, no - there is still the PERLIO_FILE_file() problem, which was |
From @LeontOn Thu, Apr 19, 2018 at 6:25 PM, Steve Hay via perl5-porters
I don't quite understand why it's accepting that in C mode, casts Wouldn't the attached fix that? Leon |
From @Leont0001-Make-PERLIO_FILE_file-an-lvalue.patchFrom 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
|
From @bulk88On Thu, 19 Apr 2018 09:17:31 -0700, xsawyerx@cpan.org 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. -- |
From @bulk88On Thu, 19 Apr 2018 23:08:56 -0700, bulk88 wrote:
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? -- |
From @steve-m-hayOn Thu, 19 Apr 2018 10:34:04 -0700, LeonT wrote:
Yes. Thanks - now applied in commit 002a841. |
From @steve-m-hayOn Fri, 20 Apr 2018 17:23:46 -0700, bulk88 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.) |
From @iabynOn Mon, Apr 23, 2018 at 05:59:21AM -0700, Steve Hay via RT wrote:
I'll have a look -- |
From @iabyn
Well, a simple revert caused g++ to break on linux: In file included from POSIX.xs:19:0: -- |
From @iabynOn Mon, Apr 23, 2018 at 03:01:59PM +0100, Dave Mitchell 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 -- |
From @LeontOn Tue, Apr 24, 2018 at 12:52 PM, Dave Mitchell <davem@iabyn.com> wrote:
I would guess that making them EXTCONST again, but putting them inside Leon |
From @iabynOn Tue, Apr 24, 2018 at 02:56:00PM +0200, Leon Timmermans wrote:
That seems to work under linux. Does someone want to try it on Windows? -- |
From @steve-m-hayOn 24 April 2018 at 15:49, Dave Mitchell <davem@iabyn.com> wrote:
That fixes the problem for me. But I spoke to soon in claiming that the build otherwise worked with Socket.xs(804): 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 { STR_WITH_LEN("next"), OPp, STRUCT_OFFSET(struct op, op_next), }, which becomes: { ("" "next" ""), (sizeof("next")-1), 0x3, 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, and if I insert "#undef STRUCT_OFFSET" before that (to get rid of the *That* really is the last problem. With that hack in place the build |
From @bulk88On Tue, 24 Apr 2018 09:23:38 -0700, shay wrote:
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). -- |
From @steve-m-hayOn 27 April 2018 at 14:56, Leon Timmermans <fawaka@gmail.com> wrote:
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 Socket.xs(804): error C2132: syntax error: unexpected identifier So now I see there is an obvious solution that I could employ (add |
From @iabynOn Fri, Apr 27, 2018 at 06:28:42PM +0100, Steve Hay via perl5-porters wrote:
Socket is the only non-core module (i.e. outside of ext/) which uses Commit v5.27.5-31-g346712be0b modified core to assume stddef.h and -#if defined(STANDARD_C) && defined(I_STDDEF) && !defined(PERL_GCC_PEDANTIC) Perhaps that chunk should be reverted for now? -- |
From @LeontOn Sat, Apr 28, 2018 at 12:09 PM, Dave Mitchell <davem@iabyn.com> wrote:
Reverting it literally requires reverting more of Aaron's C89 work Leon |
From @steve-m-hayOn 28 April 2018 at 12:38, Leon Timmermans <fawaka@gmail.com> wrote:
Ok, that makes sense of it. The old definition only needs to be used for VS2017 onwards, though - |
From @steve-m-hayOn 28 April 2018 at 12:59, Steve Hay <steve.m.hay@googlemail.com> wrote:
Now in blead in commit 4bd4e93. (Actually, I'm still confused why Socket failed given that Windows That just leaves the GCC fixes from bulk88 to deal with on this |
From @iabynOn Sat, Apr 28, 2018 at 03:12:58PM +0100, Steve Hay via perl5-porters wrote:
Are tou likely to be able to look at these? -- |
From @steve-m-hayOn 10 May 2018 at 10:29, Dave Mitchell <davem@iabyn.com> wrote:
Yes, I will do. Sorry for the delay. Not even being able to build in |
From @arcSteve Hay via perl5-porters <perl5-porters@perl.org> wrote:
C++ restricts use of offsetof() to (roughly speaking) the C-like -- |
From @steve-m-hayOn 10 May 2018 at 14:01, Steve Hay <steve.m.hay@googlemail.com> wrote:
Finally tried this out, using MinGW-w64 compilers (6.3.0 and 7.1.0). I I noticed that config_sh.PL corrects longdblsize (and uses it for unless ($opt{cc} =~ /\bcl/) { One minor thing, though: config_sh.PL also adjusts longdblinfbytes and The other thing I noticed is that lib/ExtUtils/t/Embed.t fails in the 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 gcc -c -xc++ -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE |
From @iabynOn Mon, May 14, 2018 at 06:03:02PM +0100, Steve Hay via perl5-porters wrote:
Should this work so far be applied in time for an -RC2? -- |
From @steve-m-hayOn 22 May 2018 at 09:55, Dave Mitchell <davem@iabyn.com> wrote:
Yes, I think so. It's not complete, but it's an improvement on the I don't think the C++ build trouble is a showstopper anyway. Most |
From @steve-m-hayOn 22 May 2018 at 17:52, Steve Hay <steve.m.hay@googlemail.com> wrote:
I've now pushed the main patch here in commit I will do that in the next couple of days unless anyone objects. |
From @steve-m-hayOn Thu, 24 May 2018 05:42:29 -0700, shay wrote:
Now removed from blockers list. |
|
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 (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. |
|
For your information. The |
|
Seems that @steve-m-hay's build does not include the @twata, I take it that you did also specify I think the issue with Net::SSLeay and OpenSSL-3.0.8 should be raised at https://github.com/radiator-software/p5-net-ssleay/issues. Cheers, |
Yes. I edited the Makefile as follows.
No. A rough outline of what I have done is as follows. Download perl-5.38.0-RC1.tar.gz from metacpan(https://metacpan.org/release/RJBS/perl-5.38.0-RC1).
Thanks for the advice! Thank you, |
Well, that might be the case. (If you create the "issue" then some well-informed person should be able to clarify.) I see that the latest Strawberry Perl development release (https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/download/dev_5.38.0_RC2_20230626_gcc13/strawberry-perl-5.38.0.1-RC2-64bit-portable.zip) ships with openssl-1.1.1q - so maybe the Net::SSLeay source hasn't made the migration to openssl-3. The last post in this thread from @steve-m-hay was received over 12 months ago and I'm thinking that whatever it was that prevented his build from working has since been fixed. I've just tried building perl-5.38.0-RC2 using Steve's method: I can see the I therefore think that this issue could be closed, though we should probably wait for confirmation from @steve-m-hay. @twata1, thanks for chasing this up. Cheers, |
Yes, it's been fixed since. The -std:c++20 flag was added on 24 May this year (commits 2adc710 and 97a167a). The USE_CPLUSPLUS build with Visual Studio 2022 (MSVC143) now works for me. nmake CCTYPE=MSVC142 USE_CPLUSPLUS=define |
|
According to https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170 Furthermore, changing to Cheers, |
This switch was added in the 16.11 update to Visual C++ 2019. |
Migrated from rt.perl.org#132955 (status was 'open')
Searchable as RT132955$
The text was updated successfully, but these errors were encountered: