A request to backport a commit to perl 5.16 #13745
Comments
From @craigberryI received this request privately from one of the macports folks and I'm opening a ticket to get it properly considered. The short version is whether 7db66e1, "A more C++-friendly dNOOP," can be backported to maint-5.16 to fix a problem with newer, stricter versions of clang++. Begin forwarded message:
The problem is readily illustrated by configuring a build of maint-5.16 as of v5.16.3-9-g7aa08a0 with -Dcc=clang++ when the clang++ version is: $ clang++ --version This is what comes with XCode 5.1.1, but how one acquires the relevant version of clang++ probably doesn't matter. The build falls down hard like so: `sh cflags "optimize='-O3'" mro.o` mro.c The problem doesn't exist in 5.18.x and later because I fixed a similar problem for the OpenVMS C++ compiler as follows: commit 7db66e1 A more C++-friendly dNOOP. The problem with Perl___notused under C++ is that in some cases Except that one very picky C++ compiler (HP C++ for OpenVMS) sees Inline Patchdiff --git a/perl.h b/perl.h
index 3d89f8a..798e7b7 100644
--- a/perl.h
+++ b/perl.h
@@ -359,7 +359,11 @@
/* Rats: if dTHR is just blank then the subsequent ";" throws an error */
/* Declaring a *function*, instead of a variable, ensures that we don't rely
on being able to suppress "unused" warnings. */
+#ifdef __cplusplus
+#define dNOOP (void)0
+#else
#define dNOOP extern int Perl___notused(void)
+#endif
#ifndef pTHX
/* Don't bother defining tTHX and sTHX; using them outside
The problem with backporting this as-is is that's it's not binary compatible. If the core is built with C++ after this patch, the Perl___notused symbol goes missing from libperl. A previously-built extension looking for that symbol at run-time would blow up. However, if building the core is only supported for C, and C++ is only supported for extension building, it might be ok because the Perl___notused symbol will still be present in a libperl built with C. So that's one potential answer. Another is to provide the Perl___notused symbol somewhere such as mathoms.c when building with C++. The perl -V info below reflects the platform where the issue was reproduced but not the compiler used since you don't even get as far as miniperl with clang++. $ ./perl -Ilib -V Characteristics of this binary (from libperl): ________________________________________ "... getting out of a sonnet is much more |
From @xdgOn Sat, Apr 19, 2014 at 12:15 PM, Craig A. Berry
Unless binary compatibility can be assured, I don't think this should But patching mathoms.c might need to wait until 5.21. At which point, David -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @tonycozOn Sat Apr 19 09:15:09 2014, craigberry wrote:
We don't ever define the symbol, so I don't see how extensions could rely upon it. Tony |
From @craigberryOn Apr 20, 2014, at 6:58 PM, Tony Cook via RT <perlbug-followup@perl.org> wrote:
Of course! In which case 7db66e1 should be completely safe to backport. Regarding David's comment, maint-5.16 is still supported for another month and the building of any C++ extensions in a common environment is broken without this, so IMO it should be backported. "... getting out of a sonnet is much more |
From @LeontOn Mon, Apr 21, 2014 at 2:59 AM, Craig A. Berry <craigberry@mac.com> wrote:
Seems reasonable, but are we really going to release another 5.16? Not that Also, it squicks me a bit for not being a declaration like it claims, even Leon |
From @karenetheridgeOn Mon, Apr 21, 2014 at 04:03:25PM +0200, Leon Timmermans wrote:
Are there any other commits in maint-5.16 that haven't been released (or |
From mojca@macports.orgDear Developers, I would really like to see the following commit or something http://perl5.git.perl.org/perl.git/commit/7db66e12883f0832ca80164b723768b848187bda?f=perl.h See: With the latest XCode 5.1 upgrade and stricter syntax checks in clang As a consequence a lot of modules/packages (like wxPerl) are broken (I didn't test with 5.14 or 5.12, so maybe a similar trick is needed Mojca |
From @tonycozOn Sun Apr 20 16:58:22 2014, tonyc wrote:
FWIW, +1 from me. I don't expect we'll do a release though. Tony |
From @tonycozOn Tue Apr 22 18:28:54 2014, mojca@macports.org wrote:
This is a duplicate of 121686, so I've merged 121714 into that. As a summary of the discussion: it's seems safe to backport that change, but it's unlikely there will be a 5.16.4 release, since 5.20.0 will be released soonish, putting 5.16 outside of the maintenance window. Tony |
From @jkeenanOn Wed Apr 23 16:41:42 2014, tonyc wrote:
perl-5.20 has been released, so perl-5.16 is outside the maintenance window. Can we close this ticket? Thank you very much. -- |
From @bulk88On Sun Oct 19 16:21:32 2014, jkeenan wrote:
This does sound like a pretty bad bug if all C++ building was broken on 5.16, but it requires a developer suite upgrade on OSX to trigger. IDK how Devel::PatchPerl plays into this bug/ticket. -- |
From @jkeenanOn Sun, 19 Oct 2014 23:21:32 GMT, jkeenan wrote:
5.16 was released 7 years ago, so there will be no more maintenance releases. Closing ticket. Thank you very much. -- |
|
@jkeenan - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#121686 (status was 'rejected')
Searchable as RT121686$
The text was updated successfully, but these errors were encountered: