"Manisha Mirajkar" <[EMAIL PROTECTED]> wrote on 10/07/2003
08:51:19 AM:
> Hi,
> When using embedded perl in my C++ application, I want my C
> application to be able to work with perl scripts which has external
> modules e.g POSIX.
> i.e. I want these external perl modules to be loaded dynamically.

I think that I would state your requirement as "I want extensions
to be loadable".  Whether they are loaded dynamically or statically
is a matter separate from whether they are loadable at all.
An application that embeds perl may chose to embed a statically
linked perl or a dynamically linked perl.  It may do so dynamically
or statically.

> In this case all I need to do is:
> - Link my C application with libperl.a and DynaLoader.a libraries i.
> e static linking with these libraries.
>   The DynaLoader will then take care of loading the external perl
> modules e.g POSIX dynamically.
>   Is this true?

Whether DynaLoader is involved depends on whether the extensions
to perl (not mere modules, but extensions) are set to load
dynamically or statically linked into a larger libperl.

>   I saw in README.os390 whuich states that if you wish dymanic
> loading capability in your perl, then you need to use -Dusedl flag
> when configuring perl.
>   But this dynamic loading and the one I mentioned above is
> different according to what I have understood. Is this correct?

You've mentioned dynamic loading in three separate paragraphs.
You have not specified how you intend to link the application that
embeds perl.  You could link it to load code dynamically or you
could link it to load code all at once (statically).  Similarly
you can configure a build of perl to load extension code
dynamically (this is not the default on OS/390) or you could
configure a build of perl to load extension code statically
(this is the default).  If you intend to do extensive work with
dynamic loading be prepared to specify your LIBPATH environment
variable on OS/390 carefully.

> Can somebody please clarify my doubts

I hope the above has helped a bit.

Peter Prymmer

Reply via email to