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.
In reply to Re^2: Warning. No Inline C functions bound to Perl
by BrowserUk
in thread Warning. No Inline C functions bound to Perl
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |