Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the ExtUtils-ParseXS CPAN distribution.

Report information
The Basics
Id: 70150
Status: rejected
Priority: 0/
Queue: ExtUtils-ParseXS

People
Owner: Nobody in particular
Requestors: TODDR [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 3.02
Fixed in: 2.2206



Subject: Could not find a typemap for C type 'Image::Magick'
As of the release of ExtUtils::ParseXS 3.02, Image::Magick appears to have stopped compiling. The module is unfortunatley incompatible with CPAN Testers so it's hard to see the problem from there. Gentoo forums appear to be the only ones on the internet talking about the break at this point. http://forums.gentoo.org/viewtopic-p-6777870.html The break seems to be repeatable via: wget http://cpansearch.perl.org/src/JCRISTY/PerlMagick-6.71/Magick.xs perl /usr/local/lib/perl5/5.8.8/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.8.8/ExtUtils/typemap Magick.xs > Magick.xsc Could not find a typemap for C type 'Image::Magick' in Magick.xs, line 2404 I was hoping you might be able suggest why the break is suddenly happening. Maybe it's a bug in their implementation of XS?
The code in question is attached. void Animate(ref,...) Image::Magick ref=NO_INIT ALIAS: AnimateImage = 1 animate = 2 animateimage = 3 PPCODE:
Hi Todd, thanks a lot for the bug report! I see nothing particularly devious about the XS code in question. Things are a little busy at work right now and I'll be at YAPC in Riga next week, but I'll try to find some time to test & debug this. I wouldn't mind being beaten to a patch at all, though. :) Cheers, Steffen
I just had a quick look. Here's what I found: PerlMagick does not come with a typemap. The error is generally speaking valid from an XS-parser/compiler point of view. In a nutshell, PerlMagick reimplements their very own version of what a typemap for an "Image::Magick" perl type would have been. Somehow in old versions of ExtUtils::ParseXS, it seems like you could forgo the whole typemap system by defining the C type of the C++-class-munged name. From the PerlMagick code: typedef void *Image__Magick; /* data type for the Image::Magick package */ Since Image::Magick is parsed as a C++ namespace/class name, it's munged to use underscores in C by ExtUtils::ParseXS by default. I assume this is why the above definition is working in older versions of EU::PXS. I do think that typemap handling has become slightly stricter in newer versions, maybe too strict. But either way, my current understanding is that PerlMagick is bending the rules too far by relying on implementation details that bypass the "there is no such typemap" error checking. I am not sure this is reasonably fixable in ExtUtils::ParseXS. But I might be full of shit and not know it yet. I don't currently have a way to actually compile Image::Magick due to missing the actual library (specifically complaints about magick/MagickCore.h), but a simple "ignore this type" style typemap gets me past the xsubpp error people have encountered: TYPEMAP Image::Magick T_IMAGE_MAGICK INPUT T_IMAGE_MAGICK /* nothing to do */ OUTPUT T_IMAGE_MAGICK /* nothing to do */ I'll file a ticket with PerlMagick, too.
Steffen, your analysis looks good to me. It looks like RT isn't watched by the IM folks, so I reported the RT on their website. Thanks for taking the time to look at this. Todd
Marking this ticket as rejected since it's a bug in PerlMagick. Replying to this should re-open the ticket if necessary. --Steffen