Posted on

LAPACK/BLAS passed – almost

There is still one thing to do in VMS_AUTH64.exe: if a line – typically a comment) exceeds some size (assumed 256 bytes) the program fails on “input line too long”. The answer is to edit the source, limit the comment lines to 128 bytes (or so) so it won’t hurt anymore.

In fact, all will now compile, but in the end of BLAS.TESTING there is a problem to be solved:

link/exec=xblat2s_64.exe sblat2_64.obj,[--]libblas.olb/lib
%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM, lsame64__
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__SGBMV_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__SGEMV_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__SSBMV_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__SSPMV_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__SSPR2_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__SSPR_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__SSYMV_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__SSYR2_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__SSYR_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__STBMV_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__STBSV_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__STPMV_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__STPSV_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__STRMV_64__ file USER:[etw.Lapack380]libblas.olb;2
%LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
in psect $LINK$ offset %X00000030
in module DUMMY__STRSV_64__ file USER:[etw.Lapack380]libblas.olb;2
%MMS-F-ABORT, For target xblat2s_64.exe, CLI returned abort status: %X10648268.
%MMS-F-ABORT, For target all, CLI returned abort status: %X10EE8034.

No idea where that comes from. I found one file that defines it: DOPMTR_64.f:
...
* =====================================================================␍
SUBROUTINE DOPMTR( SIDE, UPLO, TRANS, M, N, AP, TAU, C, LDC, WORK,␍
$ INFO )␍
!DEC$ ATTRIBUTES ALIAS:'dlarf64__' :: dlarf
!DEC$ ATTRIBUTES ALIAS:'dopmtr64__' :: dopmtr
!DEC$ ATTRIBUTES ALIAS:'lsame64__' :: lsame
!DEC$ ATTRIBUTES ALIAS:'xerbla64__' :: xerbla
!DEC$ ATTRIBUTES ADDRESS64 :: AII
...

and there are quite a lot of sources that define LSAME – as a logical
* .. External Functions ..␍
COMPLEX*16 ZLARND␍
DOUBLE PRECISION DLARND␍
LOGICAL LSAME␍
EXTERNAL ZLARND, DLARND, LSAME␍
* ..␍
It may be that there was something during build that failed.

Posted on

Building lapack package once more

Lapack again

Re-installed lapack 3.8.0 from the netlib.org site, via via: the tar.gz file didn’t untar on VMS, so did it on the workstation, zipped the result and transferred that to Diana – and that did indeed unzip properly. Next, unzipped the VMS_Patch.zip onto the machine and copied the files into Lapack3.8.0 – as is done specificly. Started mms to build it all: and ran into the very same issues as before.: It meant I might need to changed sources (comment lines too long, so split them up). But I did have made changes before to cope with that, and that version was not on SSY$LIBRARY as supposed in decrip.mms but in a separate, central directory. I had to make another change in that code, LINK added the full path – including “000000” – to the filespecification in the .MAP file…
One that was done, the second descript.mms file still helt the “make” command – the image was added in the same central directory, downloaded from TU Delft as well and build locally – but that found the Makefile descrtiption that doesn’t hold the ‘lapack’ target so failed. Changed that to mms – and now it builds…

Posted on

all Fortran done

Finished all “executables” – at least, the fortran compilations. Still need to test the compilations, this hasn’t been done in parallel with translation, as I did with the modules.
All C and C++ compilations and LINK statements need to be checked for all otions, I could use the Numpy compilations by Brett. But include-options, and all files to be used in LINK must be checked by trail and error: most are known but numpy, lapack and blas are needed – and both can be done.
Also, some files need to be located – they are copied to the BUILD environment on Linux – and I need them to be read from the base.

Posted on

More translations

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.

Posted on

Next set of translations

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