develooper Front page | perl.perl5.porters | Postings from February 2018

[perl #132876] ppport.h breaks croak_xs_usage() on old Perls

Thread Next
Tony Cook via RT
February 21, 2018 04:04
[perl #132876] ppport.h breaks croak_xs_usage() on old Perls
Message ID:
On Sat, 17 Feb 2018 10:51:15 -0800, wrote:
> The current version of ppport.h will define croak_xs_usage() if it
> is used on a pre-5.10.1 Perl.  This definition takes precedence over
> the definition generated by ExtUtils::ParseXS, and so will be used
> by generated XS boilerplate code, not just where it is explicitly
> called by user code.  However, by default the ppport.h definition
> of croak_xs_usage() is broken, referring to an external symbol
> "DPPP_my_croak_xs_usage" that is never defined.  This will break
> almost
> any XS code that uses such a recent ppport.h, when compiled with an at
> all recent ExtUtils::ParseXS on a pre-5.10.1 Perl.
> An individual XS module can avoid this problem by defining the flag
> macro
> "NEED_croak_xs_usage" before #including ppport.h.  This causes
> ppport.h to
> provide a working definition of croak_xs_usage() instead of the
> default
> broken one.  Observe that I applied this workaround to PathTools in
> commit 08401071a36d8855d06553b44b678e51d33f09e5, anticipating that it
> might get a CPAN release soon and that that release might bundle the
> current ppport.h.  (PathTools has an explicit call to
> croak_xs_usage(),
> not just the ones implicit in the XS; this is a red herring.)
> Individual XS modules should not have to define this flag macro if
> they
> are not making explicit calls to croak_xs_usage().  ppport.h should
> not
> by default break the code generated by ExtUtils::ParseXS.

Do the attached fix this for you?


via perlbug:  queue: perl5 status: new

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About