Tag: SciPy

Most are short and C had a few fortran ones (one big), but there are a few includes I cannot place for now; will be testen tomorrow.

Still 55 to go.

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

Now I know how to set things up – in real;
SCIPY_BASE: refers to the package as it has been extracted from the .ZIP file
SCIPY_VMS: refers to the same structure to contain sources that have been adapted to compile on OpenVMS (well, only if needed, not now)
SCIPY_ROOT: refers to both of SCIPY_VMS, followed by SCIPY_BASE (currently just SCIPY_BASE because SCIPY_VMS is still empty).
SCIPY_WG: refers to the location where I create all files to set things up,define them and build the package; all code references are to SCIPY_ROOT so it code requires updates to be compiled in openVMS, I can still use the build proceduee without changes.

one of these files is – obviously – BUILD.COM. In the process of adding subsystems, I added the ability to build ALL or one package, so addition scan be tested without the requirement of redoing all what already had been done.

I could not refer to the logical name of the disk (USER:) but had to user the translation, otherwise I could do $ SET DEF but $ DIR would fail…

Now it has been determined what Fortran options will be used, it is time to work my way forward through all the Fortran compilations, subsystem by subsystem: Add each of the the build-proceduree and run them. As some point there is C-code, but this is bypassed for now: there are a LOT of options in the Linux build output. But for the Fortran code: it seems straight forward for now. I got the the point now where it seems that some numpy code is included – but Fortran code compiles with no problems where this is missing.

Now: just over halfway the fortran code (estimated).

It has been quite some time ago since I did compile Fortran programs, these were administrative in stead of mathematical, so I needed to check the Fortran manual for the right options; Found what I could extract from the outputted building-log I got from Linux: The compilation succeeded with no error or warning, so that is Ok. Now getting on in building SciPy, subsystem by subsystem; where I need Numpy objects, I can use Brett Cameron’s file to create them: although this is C-only (since Cygwin seems to lack a Fortran compiler) this is fine to start with. And where I need LAPACK and BLAS, I can always fall back on what’s done by Jouk Janssen.
Since SciPy holds a number of ‘subsystems’ for several types of calculations, I intend to take them one by one and have then compiled successfully, and create an object library for each of them. In the end a shared image, but for that, I may have to do the same for numpy – it also contains a number of Fortran sources.

Now I’m in full control of what directory structure is to be used in building it all, I will set things up the way I think is right:
SCIPY_BASE: is the original package, and SCIPY_WG is created aside (not inside) it. Here, I place all files needed to build what’s in SCIPY_BASE, all results come in SCIPY_WG: object files in [.OBJ]. list and map-files in [.LIS], libraries in [.LIB] and executables in [.EXE]. SCIPY_ROOT: will refer to SCIPY_BASE. if no changes to code are required.
Whenever SpiPy code needs to be adjusted, there will also be a SCIPY_VMS: that will need to have the very same structure as SCIPY_BASE; SCIPY_ROOT: will then be referring SCIPY_VMS:,SCIPY_BASE:

The same will apply to Numpy, so the original environments will not be contaminated.

LAPACK is another story. I could do the same there, but that requires quite a lot of work the way it is set up now: the VMS-structure is inside the package, and it requires quite a lot of extensions in both structures before LAPACK_ROOT: can refer to LAPACK_VMS:,LAPACK_BASE:. So I leave it as it is – for now.

In reading the Fortran manual (of 2005, I have no more recent version) I came along the CXML – C(ompaq?) Extended Math Library – that contains LAPACK and BLAS, but also parts of SciPy. The doc mentioned “Alpha only”, so its current (and future) state are questionable. Anyway, I will proceed with the plan – using CXML is bi big deal – just the object(s) in LINK command will change.

Now I got the output (3 weeks ago :), almost 6000 lines were outputted. I started locating the real building commands: every line noting gfortran, gcc or g++. The real work seems to start around line 4000, where there is a line
building 'dfftpack' library
From there on, the real works seems to start, library after library. That is: in Linux terms.
All lines before seem to set up a building environment – probably depending on something that is not clear in the output; though it seems mostly copying sources to a BUILD directory, and all compilations are executed on these files. Therefore, first focus is on the compilations, not the copy – lines.
Now I have located the real work (set up the compiler options, execute the compiler and following activities like adding the output to a library), it’s time to translate these into the right DCL commands…

(It took so long because there were quite a few other s=things I needed to get my hands on…)