Burak has asked for the wisdom of the Perl Monks concerning the following question:

I saw an interesting module called Module::ThirdParty today. It mentions a module called Perl::API by Gisle Aas, however, it does not show up on cpan search and this looks like a bug in the cpan site. Anyway, it is accessible with a direct link: http://search.cpan.org/dist/Perl-API/ I'm using ActivePerl 5.8.8.819 under Windows XP SP2 and using MS VC++ 6 SP5. Perl::API only includes a Makefile.PL and it generates API.pm and API.xs on the fly from perlapi.pod. I' ve tried to compile it but got this error:
nmake Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. C:\Perl\bin\perl.exe C:\Perl\lib\ExtUtils\xsubpp -typemap C:\ +Perl\lib\ExtUtils\typemap API.xs > API.xsc && C:\Perl\bin\perl.exe - +MExtUtils::Command -e mv API.xsc API.c Error: 'MAGIC *' not in typemap in API.xs, line 343 Error: 'STASH *' not in typemap in API.xs, line 481 NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x1' Stop.
I'm not familiar with perl internals, but the error message suggests that a fix needed for C:\Perl\lib\ExtUtils\typemap file (well, I can be completely wrong)? So, how can I compile this code? Any suggestions?

Replies are listed 'Best First'.
Re: How to compile Perl::API?
by ferreira (Chaplain) on Jan 25, 2007 at 17:13 UTC

    Well, I don't have many clues about Perl internals as well. But it looks like Perl-API is a very experimental work by Gisle Aas and was previously tested only for versions up to 5.8.5. The changes in later versions apparently broke the ad-hoc magic of the distribution.

    It can be restored by applying the following patch to Makefile.PL:

    --- Makefile.PL 2007-01-25 15:05:56.000000000 -0200 +++ mk.pl 2007-01-25 15:06:54.000000000 -0200 @@ -77,10 +77,11 @@ if ($args =~ /\.\.\./ || $args =~ /\*\*/ || $args =~ /\b(PerlInterpreter|PADOFFSET|const)\b/ || - $args =~ /(STRLEN|I32|U8|int|[INUG]V|HE|PerlIO)\s*\*/ || + $args =~ /(STRLEN|I32|U8|int|[INUG]V|HE|PerlIO|MAGIC|STASH)\s*\*/ + || $args =~ /(^|,)\s*(sv)?type\b/ || $ret =~ /\*\*/ || $name =~ /^X?PUSH/ || + $name =~ /^SvREFCNT/ || $AVOID{$name} || 0) {

    The patch only adds declarations with MAGIC and STASH into the stuff marked as "some we can't handle yet" and the same for names starting with SvREFCNT.

    I am not sure of how much the distribution is usable, because if you uncomment the various print statements you will see that many parts of the API are skipped as the simple configuration script is not able to build the XS binding to them. But it doesn't stop you of fixing this state of things and probably Gisle will appreciate a patch to improve the general state of the distribution.

    Update: filed at the Perl-API RT queue as rt.cpan.org #24585.

      Thanks. Your patch solved the problem. I don't think that this thing is created for serious programming, but it looks like a nice toy :)
Re: How to compile Perl::API?
by syphilis (Archbishop) on Jan 25, 2007 at 17:16 UTC
    Firstly, note that this module was created on 09 Oct 2003, and has not been updated since.

    Also, note that on http://cpantesters.perl.org/show/Perl-API.html#Perl-API-0.01 it is reported as passing on Win32, perl-5.6.1. I went so far as to verify that it did, indeed, build successfully on perl-5.6.1, Win32, (which it does). And I also found that it fails for me on perl-5.8.8, Win32, in exactly the same way as it failed for you.

    When I compare the generated xs files (ie the API.xs generated under 5.6.1 versus the API.xs generated under 5.8.8) I find that the file generated with 5.8.8 contains a couple of extra functions - namely:
    void SvMAGIC_set(SV* sv, MAGIC* val)
    and:
    void SvSTASH_set(SV* sv, STASH* val)
    If I comment out those four lines (use #) then the 'make' and 'make test' steps proceed without error. (I'm using 'dmake' instead of 'nmake' ... and I'm using the MinGW compiler instead of MSVC++ 6.0 ... but I doubt that has any bearing on the issue).

    Does that resolve things for you ... or do we need to look further ?

    It's an interesting little issue, so looking further would not be an entirely burdensome task :-)

    Cheers,
    Rob
      Well... Yes, commenting out the error lines solves the problem partially, but ferreira' s patch seems better :)