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

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

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

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.

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