Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

weird XS_unpack_charPtrPtr error

by tlm (Prior)
on Apr 04, 2009 at 01:43 UTC ( #755383=perlquestion: print w/ replies, xml ) Need Help??
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
Re: weird XS_unpack_charPtrPtr error
by BrowserUk (Pope) 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

    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.
Re: weird XS_unpack_charPtrPtr error
by syphilis (Canon) 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
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 () { ... }
    or even
    static void foo (); ... static void foo () { ... }
    ...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

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://755383]
Front-paged by tye
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2014-09-19 04:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (129 votes), past polls