http://www.perlmonks.org?node_id=1049808


in reply to Extending perl with C dynamic library.

Here is what happens when you write a small pure C function and build it with Inline::C.

Start with the C function and the Inline::C support structure:

#! perl -slw
use strict; use Config;
use Inline C => Config => BUILD_NOISY => 1, CCFLAGS => $Config{ccflags
+}." -DDEBUG=1";
use Inline C => <<'END_C',  NAME => 'ICexample', CLEAN_AFTER_BUILD =>0
+;

int add( int a, int b ) {
    int result;
    result = a + b;
    return result;
}
END_C

my $a = 12345;
my $b = 23456;
my $c = add( $a, $b );

print $c;

[download]

When you run that, Inline::C wraps that C function up with an XS function to call it into a .XS file which gets XS-preprocessed to a .c file which is what gets compiled to create the dynamic llibrary (.dll/.so). Here I've thrown away a lot of boilerplate code to make it easier to see what is going on. The resultant .c file contains 3 functions.

The original C function:

int add( int a, int b ) {
    int result;
    result = a + b;
    return result;
}

[download]

A wrapper function that unpacks the input arguments from their Perl variables; calls the C function with the extracted values; and then wraps up the return value from the C function into a Perl variable for returning to the Perl code:

XS_EUPXS(XS_main_add) {
    dVAR; dXSARGS;
    int    a = (int)SvIV(ST(0))
    int    b = (int)SvIV(ST(1))
    int    RETVAL;
    dXSTARG;

    RETVAL = add(a, b);
    XSprePUSH; 
    PUSHi((IV)RETVAL);
    XSRETURN(1);
}

[download]

And finally, it adds a bootstrap function who purpose is two-fold:

  1. to provide a known entrypoint that bootstrap can call in the .dll/.so; The name is always 'boot_' + the name of the dll/.so file.
  2. To return the Perlish names of the function the .dll/.so exports -- these are the XS wrappers around the C functions -- and their entrypoint addresses so these can be fixed up in the Perl programs symbol table and thus become callable from Perl. 
XS_EXTERNAL(boot_ICexample) {
    dVAR; dXSARGS;
    const char* file = __FILE__;

    XS_VERSION_BOOTCHECK;

    newXS("main::add", XS_main_add, file);
   XSRETURN_YES;
}

[download]

So, you should be able to see from this that you cannot avoid the XS wrapper functions because the C code would not know what to do with perl variables. And you cannot do away with the 'boot_module' entrypoint because perl would not know what functions are exported by the .dll/.so.

I strongly urge you to play with Inline::C and explore the files it creates. You'll learn far more, far more quickly that banging your head on the wall of ignorance trying to go your own way.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.

Replies are listed 'Best First'.
Re^2: Extending perl with C dynamic library.
by Martin90 (Sexton) on Aug 17, 2013 at 12:26 UTC
    BrowserUk , huge thanks for this !

    I've tested Inline:C version and it works almost the same way as XS. For me big adventage of Inline:C is the fact that code is more visable and well separated.

    But I didn't mentioned why I am looking for another way of produce dynamic libraries (.so) if I already have XS solution.

    The answer is .so file size. With XS and Inline::C I get .so file size aprox. 50 kb (suprisingly big for just one C function !) I have seen other people .so with much more complex code involved several function with just 10-20 Kb size.

    Well, why even simple .so weight so much ? How to slim it down ? ;)

    Thanks.
[reply]
      How to slim it down ?

      Try stripping the symbols from it: 
      strip -s your.so

      [download]
      Often, but not always, perl is built with a cflags setting that ensures that the shared object is automatically stripped.

      Cheers,
      Rob
[reply]
[d/l]
      Well, why even simple .so weight so much ? How to slim it down ? ;)

      Quite frankly, I wouldn't bother.

      If you achieved a full 40k saving it only represents 0.001% of the most modestly configured workstation or server memory.

      And that's if the whole of the on-disk representation actually gets loaded into memory, which it probably doesn't.

      And if your thought is smaller file will take less time to load. The time spent finding the directory entry and seeking to the file will completely swamp any difference in loading 10k instead of 50k. It is doubtful if you could ever actually measure any difference it might make.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      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.
[reply]
      Counter-Question: WHY do you want to use C?

      Or put differently: What is your real goal?

      Do you just want to see it work? Do you want to make something more performant? Is there something that's not implementable in perl?

      I'm asking this because shortly after trying to implement inline C you're worried about size of the resulting library. To me the first priority would be: Is it worth it? And that means some kind of performance/functionality test. Stripping down the C-beast afterwards is only necessary if there is an actual gain - otherwise stay with pure perl for easier portability, maintainability, conciseness...

[reply]

In Section Seekers of Perl Wisdom