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

Owner: Nobody in particular
Requestors: TODDR [...]

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

Subject: Could not find a typemap for C type 'Image::Magick'
Download (untitled) / with headers
text/plain 784b
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. The break seems to be repeatable via: wget 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?
Download (untitled) / with headers
text/plain 169b
The code in question is attached. void Animate(ref,...) Image::Magick ref=NO_INIT ALIAS: AnimateImage = 1 animate = 2 animateimage = 3 PPCODE:
Download (untitled) / with headers
text/plain 323b
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
Download (untitled) / with headers
text/plain 1.5k
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.
Download (untitled) / with headers
text/plain 178b
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
Download (untitled) / with headers
text/plain 132b
Marking this ticket as rejected since it's a bug in PerlMagick. Replying to this should re-open the ticket if necessary. --Steffen

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to