Doug, In the good old days of DECUS[1], I chaired the VMS Internals Working Group (for about 8 years, from 1981 through 1989, glory, halcyon days).
During each DECUS Symposium, on Thursday night, we ran a magic session, handing out a prize for the best magic (decided by a panel of VMS internals wizards using an online voting system, in hex). I'm sure your solution would have won a prize. Congratulations! And, I'm still ROFLMAOPIMP. Carl Friedberg [EMAIL PROTECTED] www.comets.com [1] DECUS == Digital Equipment Corporation Users Society, which held symposia twice a year for many, many years. > -----Original Message----- > From: doug brann [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 18, 2006 4:15 AM > To: Craig A. Berry; vmsperl@perl.org > Subject: Re: Help building a Perl Module that works under HP-UX and > Linux but not under VMS > > Well, we got it working. I should probably let all of you know what I > ended up doing to get this thing going, just in case someone else > wants to try something as weird as this project has been. > > 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 > <http://us.rd.yahoo.com/evt=42973/*http://www.yahoo.com/preview>
