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