83 to go…
The last of the modules: the first one where compilation isn’t flawless:
$ @build SC_SPECFUN
Compiling sc_specfun
IF (JM+1.GT.251) GOTO 6
.................................^
%F90-W-WARNING, A jump into a block from outside the block may have occurred. [6]
at line number 8226 in file SCIPY_BASE:[scipy.special.specfun]specfun.f;2
%LIBRAR-W-COMCOD, compilation warnings in module DNAN file SCIPY_WG:[obj]specfun.OBJ;1
$
There is indeed something wrong in this code, perhaps that gfortran is more forgiving on bad programming practices than OpenVMS Fortran…. So I may need to change this code but in such a way it works for both gfortran and OpenVMS Fortran.
Next are the real extension modules, that are called by Python: both entry points to these modules, and modules that are used for testing. Most of this is C, a few are C++ and yes, there are a few fortran modules. Split this from the module-build, but it uses the same structure: editing a smaller file is simpler.
On Linux, most of the shared objects seem to be created using gfortran, on OpenVMS this is done by LINK. Most of the options are easy determined:
LINK/THREAD/FP_MODE=IEEE/SHARE/MAP=SCIPY_LIS:/FULL/CROSS
and given the CentOS build output, it is rather simple to add all files that are included in the process: the objects built just before, and the libraries built in the module-build. But there are a few things that I need to find out: on Linux, most link:
-lpython2.7
-lgfortran
-L/usr/lib64
-Lbuild/temp.linux-x86_64-2.7
(there is, of course, a difference between -l and -L so that is to be taken into account) – have to find out what this means, and add the equivalent on OpenVMS.
63 to go