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.
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. 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.
-Doug Brann
Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business.
