You've certainly identified something that needs some attention, but "char
**" is in the typemap:

basic C types

...
char ** T_PACKEDARRAY
...
INPUT
...
T_PACKEDARRAY
$var = XS_unpack_$ntype($arg)
...
OUTPUT
...
T_PACKEDARRAY
XS_pack_$ntype($arg, $var, count_$ntype);

When one (or more) of the argument types is not in the standard typemap,
then the function simply does not bind to perl - which becomes a runtime
problem (but only if the function is called from perl).

For example, this builds fine even though "double *" is not in the typemap:

use Inline C => <<'EOC';

int foo (int i, double * x) {
return 0;
}

EOC

It only fails if we then try to call foo() from perl:

Undefined subroutine &main::foo called at try.pl line xx.

I haven't yet worked out why the "char **" invocation produces the compile
error you reported - but I can confirm that it does for me.

Cheers,
Rob

From: Ed Avis
Sent: Tuesday, May 03, 2016 7:13 PM
To: ingydotnet/inline-c-pm
Subject: [ingydotnet/inline-c-pm] Better error message when type not in
typemap (#52)

If Inline::C tries to wrap a function where one of the argument types is not
in the standard typemap, you get a build error like undefined reference
toXS_unpack_charPtrPtr'. This is a bit perplexing. It would be better to
check this earlier and produce a friendly message likefunction foo takes
parameter x of type char ** but that type is not in the typemap file`.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

Thanks for investigating. I observed the build error on Cygwin but not on Linux. If I stop using char ** then it builds OK on both Cygwin and Linux.

I should have indicated that I was using (native) Windows.
With perl-5.22.0 on both Ubuntu and Windows, I'm finding that neither of
those perls can resolve the symbol 'XS_unpack_charPtrPtr'.
However, on Windows, that's a compile-time error - whereas, on Ubuntu that's
not an error until runtime.
Hence I suspect that it's essentially the same issue on both Windows and
Linux - it's just that on Windows it's a compile-time error, whereas Linux
will compile ok and defer the error until runtime.

I don't have a usable Cygwin, so I'm guessing that the underlying Windows
system takes precedence over the Linux-emulation thereby making it a
compile-time error.

Cheers,
Rob

So ... perl gives us a typemap that references a function that is not available (_XS_unpack_charPtrPtr).
Surely this is a bug in the typemap ?

I think Inline::C is entitled to assume that the standard typemap pulls in valid code.

Should I file a bug report against perl's typemap ?
Or am I overlooking something ?

(At least I now understand the significance of #53 .)