Basically, I have a FORTRAN program that calls persist.c, which is pretty much straight out of the perlembed documentation for a persistent perl. So, persistent.c calls persistent.pl (which is pretty much also right out of the documentation). This routine in turn calls a perl script that has in it a line:
use PerlInterface;
which has several routines that call FORTRAN routines, some with arguments some that without. The trick was getting the PerlInterface.XS code to find .OBJ files that were not linked to the PerlInterface module in any way.
The solution was a bit of a hack, but in may ways anything like this project is destined to be a bit of a hack (if not more than 'a bit'). What I did was get the FORTRAN code calling persistent.c to pass an array of integers to persistent.c. Those integers corresponded to addresses in memory where the FORTRAN routines resided. Then, persistent.c used sprintf to turn those addresses into character strings, which were in turn passed to persistent.pl.
Next, PerlInterface.XS took over. A routine in the BEGIN block called the XS code, which in turn took those integers and treated them as addresses and assigned pointers to callback routines to those addresses. After that, everything worked.
There was an added advantage of this method that any script doing a 'use PerlInterface;' call will not run unless it is run from a "PERSISTENT" executable, since the callbacks in the XS code point to NULL without proper initialization. This turns out to be an added security measure since scripts running this code can do dangerous things that we can prevent from PERSISTENT.
This whole thing sounds and looks a bit ugly, and it was completely unnecessary on HP-UX or Linux, but I'm glad it got working and felt like somebody somewhere might want to know about it.
-Doug
"Craig A. Berry" <[EMAIL PROTECTED]> wrote:
At 3:50 AM -0700 10/16/06, doug brann wrote:
>I don't know if I'm sending this e-mail to the right place, but I am stuck on a weird problem building a Perl module.
vmsperl is the right place. I believe vmsperl-help is just for help
with the mailing list, not for help with Perl or VMS.
>
>I have a persistent perl executable based on the code found in the "perldoc perlembed" example, and this executable will be running scripts that use a Perl module that has a C extension that is making a call to an .obj that contains FORTRAN code (how's that for confusing?). The .obj file is known PersistentPerl, but is not known to PerlInterface. PerlInterface.XS contains a prototype of the call to the FORTRAN routine, and a routine in PerlInterface.XS contains the call to the routine.
>
>Believe it or not, the PerlInterface and PersistentPerl actually work as desired under *NIX systems. That is, when a script with 'use PerlInterface' is run under the PersistentPerl executable, a call to the FORTRAN routine behaves exactly the way it's supposed to. If that same script is run by just typing "perl [script].pl", the script can't compile. This is exactly what I need this thing to do. You can do a 'perl Makefile.PL' and a 'make install', (but not 'make test' obviously), and after that, PersistentPerl and PerlInterface work perfectly.
>
>When I ported the whole thing over to VMS, everything worked. Almost. PERSISTENTPERL compiled, and successfully linked all the FORTRAN .obj files.
What did it link them into? Did it create a shareable image (aka dynamic library)?
>I did a 'perl MAKEFILE.PL' and it created a DESCRIP.MMS for PERLINTERFACE. Then I did an 'mms install' and got a headace.
>
>%LINK-W-USEUNDEF UNDEFINED SYMBOL REFERRED IN MODULE PERLINTERFACE fiile [....path to .olb file]PERLINTERFACE.OLB
>
>%MMS-F-ABORT PL_PERLINTERFACE.EXE CLI RETURNED ABORT STATUS %X10648268
>
>I'm a real VMS novice, and mms is new to me as well, so I have no idea what is going on here. It looks to me as though I'm missing some sort of explicit call in my MAKEFILE.PL to ensure that my module doesn't try to resolve the lack of the actual code the call is trying to make.
>
>Thanks for any help you can give me.
Is there any code in PerlInterface that is expected to know how to
locate a dynamic library at run-time, i.e., any dlopen() calls or
similar?
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
Get your email and more, right on the new Yahoo.com
