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

C:\test>perl -mInline::C -wle"print $Inline::C::VERSION; warn $]"
0.44
5.008006 at -e line 1.

[download]

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));

[download]

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.

Replies are listed 'Best First'.
Re^3: Warning. No Inline C functions bound to Perl
by syphilis (Archbishop) on Feb 20, 2006 at 00:46 UTC
    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;

    [download]
    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";

    [download]
    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

    [download]
    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
[reply]
[d/l]
[select]
      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.
[reply]
[d/l]

In Section Seekers of Perl Wisdom