weird XS_unpack_charPtrPtr error

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

I've developed and tested a module that uses Inline::C. It works fine, all the tests pass, etc. But now I need to turn it into a pre-compiled, free-standing loadable module, and this is not going so well.

When I attempt to run the tests using this pre-compiled version, the loading fails with an error about not being able to find the symbol XS_unpack_charPtrPtr.

This makes no sense to me. I do have C functions in my code whose arguments include some of type char**, I even have one that takes char***, but all these functions are statics, unseen by the Perl code; these functions that take char** are called only by other C functions. Therefore I don't see why they should cause this reference to XS_unpack_charPtrPtr. If my reasoning here is incorrect (which is quite likely), please let me know.

I've tried to make a simple example that illustrates the problem, without any luck. The error shows up only when there's a substantial amount of code. (In fact, AFAICT, what I have here is a Heisenbug.)

Therefore, the only thing I can hope for is some general Inline debugging/troubleshooting advice. For starters, I would love to know how to find out which function in my code is causing Inline C to generate a reference to XS_unpack_charPtrPtr.

FWIW, I'm following the instructions given in the Inline docs, under the section "Writing Modules with Inline". This includes modifying Makefile.PL to use Inline::MakeMaker instead of ExtUtils::MakeMaker. The versions of all the modules used are the most current ones from CPAN.

Many thanks in advance!

the lowliest monk

Comment on weird XS_unpack_charPtrPtr error

Replies are listed 'Best First'.
Re: weird XS_unpack_charPtrPtr error by BrowserUk (Patriarch) on Apr 04, 2009 at 02:23 UTC
Therefore, the only thing I can hope for is some general Inline debugging/troubleshooting advice. For starters, I would love to know how to find out which function in my code is causing Inline C to generate a reference to XS_unpack_charPtrPtr. Whether it will help or not ... but you could start by adding: `#define XS_unpack_charPtrPtr ___something___never___defined` [download] at the top of your code after any #includes. That ought to cause any references to it to bellyache along with line numbers. It might give you a starting point. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l]
Re: weird XS_unpack_charPtrPtr error by syphilis (Archbishop) on Apr 04, 2009 at 03:42 UTC
But now I need to turn it into a pre-compiled, free-standing loadable module Not that it has much to do with your actual problem, but the approach you're taking will fail to create a "free-standing loadable module" - in that it will still depend upon Inline::C. Nothing necessarily wrong with that. It just struck me as something worth pointing out (in case it is relevant to your aims). If you want to avoid the Inline dependency altogether, InlineX::C2XS can convert your Inline::C code to a suitable XS file, and even write you a stub Makefile.PL and Your_Mod.pm in the process. As to the actual problem, there's nothing wrong with what you're doing (based on your description), but it is highly likely that you are doing something wrong. The stuff that you are doing usually works quite well. Inline::C does throw up some pretty strange errors at times - messages that don't really help you determine exactly what it is that you've done wrong. This could well be another example of that. Cheers, Rob	[reply]
Re: weird XS_unpack_charPtrPtr error by tlm (Prior) on Apr 06, 2009 at 23:27 UTC
A belated update. Shortly after posting, I (re-)discovered the NOCLEAN option to Inline, which enabled me to examine the generated *.c file, and from this I could see where the references to XS_unpack_charPtrPtr. So I never got to use BrowserUk's useful trick. (I've added to the old bag o' tricks for the future. Thanks.) I found that apparently `Inline` was getting thrown off by the fact that in my C code some times I had the word static in the declaration of a function, but not in its subsequent definition; e.g. `static void foo (); ... void foo () { ... }` [download] or even `static void foo (); ... static void foo () { ... }` [download] ...with the `static` keyword on a separate line. Either way, `Inline` was incorrectly treating these functions as ones to make callable from Perl. So adding the `static` keyword to the function definitions where `Inline` wanted it took care of the `XS_unpack_charPtrPtr` error. (It is a mystery to me why this problem arose only when I tried to make a downloadable package, and not before during my tests, since the C source code was exactly the same in both cases.) But as it happened, all this turned out to be for nothing, and syphilis's observations and suggestions were right on the money. What I had been trying to do did not produce the desired degree of independence from Inline. For what I needed InlineX::C2XS was indeed the right tool. Many thanks! the lowliest monk	[reply] [d/l] [select]
Re^2: weird XS_unpack_charPtrPtr error by syphilis (Archbishop) on Apr 07, 2009 at 01:07 UTC
I had the word static in the declaration of a function, but not in its subsequent definition With Inline::C, function declarations are usually unnecessary. I wouldn't go so far as to say that they're never needed, but I've not yet struck a situation where they're required. with the static keyword on a separate line It's a bug that having 'static' on a separate line is producing different behaviour. In fact, I think it's a bug in the Parse::RecDescent parsing of the code - if you parse with ParseRegExp the problem disappears. ParseRegExp is a much faster parser, too. You use it by specifying the Inline config option `USING => 'ParseRegExp',` (ParseRegExp is broken in Inline-0.44, but works fine for me in Inline-0.45.) I'm not sure if it's a bug or a feature that the static keyword makes the function invisible from perl, but that's certainly the way it is for me. I'm still a little bit puzzled that you needed to use `static` to get the desired effect. I've written plenty of Inline::C functions that are uncallable from Perl, and haven't had to do anything like that. Of course, if I call them from Perl, then I get a runtime error straight away - and they do have to be defined in the script before any of the other Inline::C functions that call them. Anyway, good that you got it working - and I much appreciate your feedback. Cheers, Rob	[reply] [d/l] [select]


There's more than one way to do things
	PerlMonks