Embedded Perl

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Hallo Rob, ( and all the Others).
Defintely I will have a look at the Inline::C Routine.
At the weekend I had a look at the XS Approch(without beeing able to read
the newsgroup before.
Unfortunately the XS Approach did not really fit into my concept.
Using XS sounded like creating an extra, external Module for perl.

My Intent is following:
* I have a C program with an embedded perl interpreter
* I want to use the perl interpreter to have a scripting language for my
* But I want to have special program-related perl commands that act on
 my programs database. If I did not want this I could use a normal perl
 interpreter from the beginning
* Therefore I somehow want to register C- callback functions under a
 dedicated perl function name.

I have written a c callback function, which draws a rectangle. It is
draw_rectangle. Then I instanciate a perl interpreter in my C program.
Then I want instruct !!!! "C" !!!! to register the callback function as
a new perl_command "draw_rectangle".
Finally I instruct the perl interpreter to execute a script from a file.
I dont mind, if the c callback functio has to evaluate the perl stack,
but It would be fine, if my function was registered in the main
namespace(no :: in function name) and if there were no measures in the
perl program to load the draw_rectangle from an external module).

There are to reasons why I dont want my "draw_rectangle" from an external
perl module
*    I dont want to keep my program as simple as possible - No extra
    files if possible
*    I fear, that the extern module is not able anymore to access the
    program database as it is seperated from the main program

Who has the perfect solution for me ?

Re: Embedded Perl

Also sprach Guenther Sohler:

Quoted text here. Click to load it

Not necessarily.

So create an XSUB and compile it statically into your program embedding
the Perl interpreter.

The easiest way I can think of:

First create an ordinary XS module using h2xs and write your XS-code.
After doing 'perl Makefile.PL; make' have a look at the .c file
generated by xsubpp (alternatively you can just create the .xs file and
run xsubpp manually on it). From this file you copy all the transformed
XSUBs and the boot-section into your C program. XSUBs look like this:

    XS(XS_Module__Name_function); /* prototype to pass -Wmissing-prototypes */

And the special boot-function:

    XS(boot_Module__Name); /* prototype to pass -Wmissing-prototypes */
    char* file = __FILE__;


        newXS("Module::Name::function", XS_Module__Name_function, file);

The boot thing will register the XSUBs under a fully qualified function
name using newXS(). Since you said that you'd like to make the functions
available in package main, change this line to:

    newXS("main::function", XS_Module__Name_function, file);

Your C program now only has to call boot_Module__Name() once after the
Perl interpreter has been constructed and initialized. Always call it


The only thing I am not quite sure of is whether the above will work out
of the box for an embedded Perl interpreter. But I think that the 'aTHX'
macro (and the invisible 'pTHX_' that is put in by the XS(name) macro)
handles passing the right Perl interpreter context to each function.

use bigint;

Re: Embedded Perl

Hallo Tassilo

Thank you for your tips.
I was able to downtrack the problem to a single function.

This works for me :)

newXS("main::rectangle", perl_rectangle, file);

but you have to call it AFTER parsing the file, else there will be a


Re: Embedded Perl

Also sprach Guenther Sohler:

Quoted text here. Click to load it

Ah, ok. I assume that this is due to perl_parse() doing some necessary
preliminary work such as setting some of the PL_* variables to some
basic values. Most notably, perl_parse() initializes the main stash
(that is, the symbol-table) so it's indeed better to have an initialized
symbol table before making entries in there using newXS.

use bigint;

Site Timeline