in reply to Warning. No Inline C functions bound to Perl

Does the code actually access any of the Inline functions ?

My understanding of that error is that perl should be unable to access any of those Inline functions - if there was even a single function that perl could access, then that error message should not appear.

Annoyingly, I can't trigger the error. According to my understanding (and based on what Google turns up) something like the following should produce the error .... but no longer does (if it ever did):
use warnings; use Inline C => <<'END_OF_C_CODE'; double * foo() { double a = 123.456, *x; x = &a; return x; } END_OF_C_CODE print "Compiled and running\n"; $z = foo();
Because there's no typemap to tell Perl how to deal with a 'double*', Perl is unable to bind to that function (though the compilation succeeds) ... and since that's the only Inline::C function in the script, I expected to see the error in question. Instead, all I get is:
Compiled and running Use of inherited AUTOLOAD for non-method main::foo() is deprecated at +try.pl line 13. Can't locate auto/main/foo.al in @INC (@INC contains: D:\pscrpt\inline +\_Inline\lib D:/perl58_M/5.8.8/lib D:/perl58_M/site/5.8.8/lib D:/perl +58_M/site/lib .) at try.pl line 13
You're running Inline-0.44 and perl 5.8.x ? (Just wondering if that particular error is an Inline-0.43 and/or perl 5.6.x feature.)

Cheers,
Rob

Replies are listed 'Best First'.
Re^2: Warning. No Inline C functions bound to Perl
by bart (Canon) on Feb 19, 2006 at 02:18 UTC
    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.

      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
        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
        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
        But no warning appears if there are both valid and invalid bindings. Ouch.
Re^2: Warning. No Inline C functions bound to Perl
by BrowserUk (Patriarch) on Feb 19, 2006 at 05:45 UTC
    C:\test>perl -mInline::C -wle"print $Inline::C::VERSION; warn $]" 0.44 5.008006 at -e line 1.

    You hit the nail on the head. Thankyou. It appears to be a missing typemap problem related to using __int64 in function args and return values.

    The program uses two separate (.pm) modules that between them load XS code compiled into 5 different modules. One of the .pm modules loads a superclass and 3 subclasses. The error only occures when I make changes to one of the subclasses. That subclass fails to be found, but all the others work. If I delete their binaries, I see the error, but the non-offending subclasses work fine.

    The problem is that the message doesn't tell you which module/package it has failed to build or produce functions for. Which in a program that builds multiple modules leaves you guessing, especially as the other modules will probably work.

    The fix might be to change the message to include that information. Something like

    ### Inline/C.pm(542) warn("Warning. No Inline C functions bound to Perl ($data->{API}{modfn +ame})\n". ## ^^^^^^^^^^^^^^^^^^^ +^^^^^ "Check your C function definition(s) for Inline compatibility\n\n +") if ((not defined$data->{functions}) and ($^W));

    That's untested. $data->{API}{module} might be more appropriate. Or both?

    Switching to doubles for passing the values in and out from/to Perl and converting internally appears to fix the problem, though there are other problems (mine!), with that subclass that mean I can't test it yet.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      For me, $data->{API} doesn't exist ... not sure of the best way to fix this. Turns out the reason I couldn't generate the error is that I now don't run using the '-w' switch. Instead I 'use warnings;' .... which doesn't set $^W. (This in itself is an Inline::C bug.)

      If I've understood, I can fairly easily re-create your situation. If I create a Foo.pm that looks like:
      package Foo; use Inline C => <<'END_OF_C_CODE'; double * foo() { double a = 123.456, *x; x = &a; return x; } END_OF_C_CODE 1;
      and a 'test.pl' that looks like:
      #!perl -w use Foo; use Inline C => <<'END_OF_C_CODE'; int foo2() { int x = 1234567890; return x; } END_OF_C_CODE print "All compiled\n";
      then when I run 'perl test.pl' I get:
      D:\pscrpt\inline>perl test.pl Warning. No Inline C functions bound to Perl Check your C function definition(s) for Inline compatibility All compiled
      with no indication that the warning was in reference to Foo.pm only.

      Is it ok with you if I file reports at rt.cpan about both bugs ? ... or would you prefer to attend to it yourself ?.
      Probably leave it up to Ingy as how he wants to deal with them. He is (or claims to be :-) currently working towards the release of Inline-0.45.

      Cheers,
      Rob
        Is it ok with you if I file reports at rt.cpan about both bugs ?

        Yes. Please do. And thanks.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.