in reply to Re^2: Calling a function form an external DLL with Inline::C on windows
in thread Calling a function form an external DLL with Inline::C on windows

I've tried it the way you did above:
int wrap_RegisterClient2(int cl_id, char* read_ip) { return RegisterClient2(cl_id, read_ip); }
but it doesn't work, I get the same error message as in the case without the wrapper.

The problem, I believe, is that unless all the parameters, and the return type, are types that the default typemap knows how to handle, Inline::C doesn't wrap and export it. And it appears that the default typemap doesn't know how to handle int *.

So, whilst this works fine:

#! perl -slw use strict; #use Inline C => Config => BUILD_NOISY => 1; use Inline C => <<'END_C', NAME => '_test', CLEAN_AFTER_BUILD => 0; int test( int i ) { return i; } END_C print test( 123 ); __END__ C:\test>test 123

This doesn't:

#! perl -slw use strict; #use Inline C => Config => BUILD_NOISY => 1; use Inline C => <<'END_C', NAME => '_test', CLEAN_AFTER_BUILD => 0; int test( int *i ) { return *i; } END_C print test( 123 ); __END__ C:\test>test Warning. No Inline C functions bound to Perl in C:\test\test.pl Check your C function definition(s) for Inline compatibility Use of inherited AUTOLOAD for non-method main::test() is deprecated at + C:\test\test.pl line 12. Can't locate auto/main/test.al in @INC (@INC contains: C:\test\_Inline +\lib C:/Perl64/site/lib C:/Perl64/lib .) at C:\test\test.pl line 12

There is the TYPEMAPS configuration option, but I haven't seen any (good) documentation on that. And finding the default typemap and looking at that doesn't yield many clues.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP an inspiration; A true Folk's Guy

Replies are listed 'Best First'.
Re^4: Calling a function form an external DLL with Inline::C on windows
by Anonymous Monk on Aug 06, 2010 at 12:58 UTC
    Seems like a correct diagnosis.

    However, it is possible to work around this issue by declaring all parameters of the wrapper functions as SV*, then manipulating their contents inside - just as you've showed it.

    Now I've written all these wrapper functions, and consequently I'm able to get data from the instrument.

    All that's left is to integrate it with the existing robot movement and EUT-driver code. I hope I won't run into any further issues with timing, serial comms, windows dark magic, etc.
      I hope I won't run into any further issues with timing, serial comms, windows dark magic, etc.

      Of course there are further issues.

      Win32::SerialPort uses Win32::CommPort which uses Win32::API to export some functions from the Windows API. And it seems that Win32::API doesn't like to work together with Inline::C - at least serial communication doesn't work with the solution derived in the posts above. I get a deluge of error messages, like
      Use of uninitialized value in subroutine entry at C:/Perl/site/lib/Win +32API/CommPort.pm line 213. Use of uninitialized value in subroutine entry at C:/Perl/site/lib/Win +32API/CommPort.pm line 247. Second Read attempted before First is done at measure.pl line 402 Use of uninitialized value $got in numeric ne (!=) at C:/Perl/site/lib +/Win32/SerialPort.pm line 1216. Use of uninitialized value in subroutine entry at C:/Perl/site/lib/Win +32API/CommPort.pm line 213. Use of uninitialized value in subroutine entry at C:/Perl/site/lib/Win +32API/CommPort.pm line 247. Second Read attempted before First is done at measure.pl line 402 Use of uninitialized value $got in numeric ne (!=) at C:/Perl/site/lib +/Win32/SerialPort.pm line 1216.
        Win32::SerialPort uses Win32::CommPort which uses Win32::API to export some functions from the Windows API.
        Where does Win32::SerialPort enter into the equation? The original question specifies that the communication is via TCP/IP, not serial.

        If there is something I missed...