ffi_call( 'Wolf!' )

doubi on 2010-06-05T00:07:37

False positive

I was pretty excited today because I thought I had my interface for ffi_call working on Linux, and told Twitter and the #soc-help channel all about it. It did seem to be working, until I changed a slight detail in my test script and it became apparent that either there was bewitchery afoot, or I need to read perlxs / perlguts more and it was random change that it hadn't blown up in the first place. I think I'm nearly there though. Next step will be fleshing out the OO functionality in Perl for a bit before diving back into the C for callbacks.

I'm having trouble getting gdb to play ball with macros though, which would be a huge help in finding out where I'm going wrong. make'ing with OPTIMIZE=-g3 (in Makefile.PL or on the command line) doesn't let me examine the stack with *SP, nor does -ggdb3 or '-gdwarf-2 -g3 -O0'. The error is always "No symbol 'SP' in this context". I keep asking people if I need a -DDEBUGGING Perl to be able to say 'p *SP[0]' at the gdb prompt but no-one's said that that's the case. Anyone have any advice on that front? The only other thing for it is even more #ifdef'd warn()s littering my XS, which takes five times as long.

I was thrown off track for longer than I'd like to admit by the fact that although xsubpp won't complain about a C-style comment after a parameter in the INPUT: section, said comment will in fact prevent xsubpp from inserting the typemap code for that parameter into the C. Moral of the story is when stuff isn't making sense, look at the .c output rather than the .xs, and sooner rather than later. Obvious in hindsight. This is what the 'student' part of GSoC is about I suppose. This and clobbering the stack. In any case, given the types of things xsubpp will usually error at you for, I think it ought to have given me a poke about this.

Nearer the start of last week I essentially wasted some time going through all three major build systems trying to configure them to build my extension correctly before settling for EUMM. I think I'll write a short musing about that in another post.

Finally, I've spent a little time cleaning up my local repo, removing h2xs / M::I stubs and the like, getting ready to push stuff public. I'm not sure about how to make sure libffi is installed for people on Win32 though. This is the kind of thing the Alien:: namespace is for I guess, but is there a standard framework for this kind of dependency checking? I know the Alien pod says there's not yet, but there may have been progress in the community since that was written. Also that pod seems to have been written by a Module::Build fan. Again, advice much appreciated.