embedding the 'perl' (newbie)

[Mirco Wahab]

Hi folks,

after fiddling around with some C++-to-perl
calls and evals (perldoc perlembed), I'm
not sure what to do now.

Maybe I'm linking the app w/perl by the options
provided by `perl -MExtUtils::Embed -e perl_inc`
and `perl -MExtUtils::Embed -e ldopts -- -std`.

The default Perl-Build creates libperl.so as a
"default", would it then be sufficient(?), to
pull the libperl.a by simply stating:

/usr/lib/perl/5.8.8/arch/CORE # ar r libperl.a `ls *.so`

out of the installed local Perl system to get
a functional static library?

What "standard" modules would then be available
to the app when linking with "ldopts -- -std"?

The real questions is: what would happen if I
bring the statically linked app to a system without
any perl (or with some version before christ)?

Thanks

Mirco

 

[Ben Morrow]

Hi folks,

after fiddling around with some C++-to-perl
calls and evals (perldoc perlembed), I'm
not sure what to do now.

Maybe I'm linking the app w/perl by the options
provided by `perl -MExtUtils::Embed -e perl_inc`
and `perl -MExtUtils::Embed -e ldopts -- -std`.

That would be the correct answer.

The default Perl-Build creates libperl.so as a
"default", would it then be sufficient(?), to
pull the libperl.a by simply stating:

/usr/lib/perl/5.8.8/arch/CORE # ar r libperl.a `ls *.so`

out of the installed local Perl system to get
a functional static library?

Did you try it? As a general rule, you can't convert a shared into a
static library.

However, my system has a /usr/lib/perl5/5.8.8/i686-linux/CORE/libperl.a,
which is a library for linking statically. Whether
gcc foo.o -L/.../CORE -lperl
links libperl.a or libperl.so is controlled by the -static option; if
you are using some other compiler I'm sure it supports the same
functionality.

If you don't have a libperl.a you can get one by compiling perl
yourself.

What "standard" modules would then be available
to the app when linking with "ldopts -- -std"?

Do you mean

Perl modules?
None. You would need to install them on the target system in
some place the embedded perl could find them. You can change
where it looks e.g. by providing a -I arg to perl_run.

Dynamic extensions?
None. See above. Note that you will need to install *all* of the
extension: the .so, the .pm, and the .bs, in the appropriate
places; maybe other stuff as well. The safest way is to have a
real Perl install on the target (of the correct version) and
install the extension properly using that; if that is
undesirable, you can look at what the extension creates when you
install it by hand and package that up in some way.

Statically linked extensions?
Typically just Dynaloader. If you want to link other extensions
statically, you can, but you will need to rebuild perl: see the
perl installation instructions for what to do. Note that you
will *still* need the appropriate .pm files installed.

You may be able to use PAR to work around some of these problems; or you
may be able to find some custom workaround. An obvious evil hack would
be to

a. Link all the extensions you need statically.
b. Convert all the .pms into C source files which define a string
constant containing the contents of the .pm.
c. Write a little C function to feed these through perl at the
appropriate time.
d. Compile it all up and link it statically.

A less evil hack would be to implement some form of custom loader,
probably starting by gutting PAR.

Ben