in reply to Re: Warning. No Inline C functions bound to Perl
in thread Warning. No Inline C functions bound to Perl

Well I do get the error, with your code snippet... but only the first time I run it. Apparently it's a warning associated to the compilation phase. The next times I run it, I only get the error message in your latter code block.

Delete the DLL subdirectories, and try again. It'll produce the error now. Once.

  • Comment on Re^2: Warning. No Inline C functions bound to Perl

Replies are listed 'Best First'.
Re^3: Warning. No Inline C functions bound to Perl
by syphilis (Archbishop) on Feb 19, 2006 at 03:54 UTC
    Perhaps the different behaviour that we're seeing might have something to do with one of my build options. What happens when you include a second Inline function - one that Perl knows full well how to handle ? Do you still get the same error message ? (I'm thinking perhaps the error really means that there's "At least one Inline C function that doesn't bind to Perl".)

    Cheers,
    Rob
[reply]
      I'm thinking perhaps the error really means that there's "At least one Inline C function that doesn't bind to Perl".
      I wish. It is what it really should be doing. But instead, I only get the warnings about AUTOLOAD. The latter appears to be something caused by Inline, it's probably introduced by how the subs and C code are connected.

      But the former is what really worries me. If you try the code with no functions at all, like with an empty code block, 

      use Inline C => <<'END_OF_C_CODE';

END_OF_C_CODE

      [download]
      then you get the warning, the first time you run it: 
      Warning. No Inline C functions bound to Perl
Check your C function definition(s) for Inline compatibility

      [download]
      But no warning appears if there are both valid and invalid bindings. Ouch.
[reply]
[d/l]
[select]
        But no warning appears if there are both valid and invalid bindings. Ouch.

        I agree - you should be told the name of any function that didn't bind. If that information included the name of the package (ie 'package_name::function'), and it was provided irrespective of the setting of $^W, then I think all of the shortcomings covered in this thread will have been addressed.

        I'm no expert on the internals of Inline, but I believe all of that should be do-able - and I'm happy to volunteer to let Ingy know.

        Ooops .... afterthought .... what if the C section of your script contains a function (not intended to bind to perl) that is needed by one of the other Inline C functions ? Under those circumstances it would be a bit annoying to be told that the function doesn't bind to perl.

        Cheers,
        Rob
[reply]

In Section Seekers of Perl Wisdom