Compilations finally succeed – but creating library doesn’t

looking for info on the internet:

https://www.fortran90.org/
http://micro.ustc.edu.cn/Fortran/Fortran%2090%20Handbook.pdf
http://www.owlnet.rice.edu/~ceng303/manuals/fortran/
https://www.fortrantutorial.com/documents/IntroductionToFTN95.pdf
https://www.fortrantutorial.com/

(could also check VMSSoftware.com – the Fortran manuals are online)

Adapt the MMS file for [.INSTALL], source for liblapack Is missing, after changing that it seems to work, until vms_auto64 is set to work with code slamch.for – the .map file isný found. Which is weird, because link worked:

cc/define=(VMS)/comment=as_is/prep=LAPACK_INS:slamch.f_ LAPACK_INS:slamch.f
fortran/name=lower/float=ieee/ieee=denorm/nowarn/list=LAPACK_LIS:/show=all/obj=LAPACK_OBJ:slamch.obj LAPACK_INS:slamch.f_
pipe link/map=LAPACK_LIS:/full/exec=nl: LAPACK_INS:slamch | copy sys$input nl:

mc ETWEXE:vms_auto64 LAPACK_LIS:slamch.map LAPACK_LIS:slamch.lis
error opening .map file
cc/define=(VMS)/comment=as_is/prep=slamch_64.f_ LAPACK_INS:slamch_64.f
%CC-F-OPENIN, error opening LAPACK_VMS:[INSTALL]slamch_64.f; as input
-RMS-E-FNF, file not found
%MMS-F-ABORT, For target slamch.obj, CLI returned abort status: %X10B9002C.
%MMS-F-ABORT, For target all, CLI returned abort status: %X10EE8034.

Makes sense because the object isn’t located where it should be

slamch.obj : LAPACK_INS:slamch.f
cc/define=(VMS)/comment=as_is/prep=LAPACK_INS:$(MMS$TARGET_NAME).f_\
LAPACK_INS:$(MMS$TARGET_NAME).f
fortran$(FFLAGS)/nowarn/list=LAPACK_LIS:/show=all/obj=LAPACK_OBJ:$(MMS$TARGET_NAME).obj\
LAPACK_INS:$(MMS$TARGET_NAME).f_
pipe link/map=LAPACK_LIS:/full/exec=nl:
LAPACK_INS:$(MMS$TARGET_NAME) | copy sys$input nl:
mc ETWEXE:vms_auto64 LAPACK_LIS:$(MMS$TARGET_NAME).map LAPACK_LIS:$(MMS$TARGET_NAME).lis
cc/define=(VMS)/comment=as_is/prep=$(MMS$TARGET_NAME)_64.f_\
LAPACK_INS:$(MMS$TARGET_NAME)_64.f
fortran$(FFLAGS)/nowarn/obj=LAPACK_OBJ:$(MMS$TARGET_NAME)_64.obj\
LAPACK_INS:$(MMS$TARGET_NAME)_64.f_
delete LAPACK_INS:$(MMS$TARGET_NAME)_64.f;*
delete LAPACK_INS:$(MMS$TARGET_NAME).f_;*
delete LAPACK_INS:$(MMS$TARGET_NAME)_64.f_;*

Neither the next definition is correct. Corrected this, next error is:

cc/define=(VMS)/comment=as_is/prep=LAPACK_INS:tstiee.f_ LAPACK_INS:tstiee.f
fortran/name=lower/float=ieee/ieee=denorm/list=LAPACK_LIS:/show=all/obj=LAPACK_OBJ:tstiee.obj LAPACK_INS:tstiee.f_
pipe link/map=LAPACK_LIS:/full/exec=nl: LAPACK_OBJ:tstiee | copy sys$input nl:

mc etwexe:vms_auto64 LAPACK_LIS:tstiee.map LAPACK_LIS:tstiee.lis
normal end
cc/define=(VMS)/comment=as_is/prep=LAPACK_INS:tstiee_64.f_ LAPACK_INS:tstiee_64.f
fortran/name=lower/float=ieee/ieee=denorm/obj=LAPACK_OBJ:tstiee_64.obj LAPACK_INS:tstiee_64.f_
delete LAPACK_INS:tstiee_64.f;*
delete LAPACK_INS:tstiee.f_;*
delete LAPACK_INS:tstiee_64.f_;*
library/crea LAPACK_LIB:liblapack.olb dlamch.obj,dsecnd_INT_CPU_TIME.obj, ilaver.obj,lsame.obj,second_INT_CPU_TIME.obj, slam
ch.obj, LAPACK_version.obj, LAPACK_version.obj tstiee.obj tstiee.obj
%DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
\TSTIEE\
%MMS-F-ABORT, For target liblapack.olb, CLI returned abort status: %X00038098.
-CLI-W-MAXPARM, too many parameters - reenter command with fewer parameters
%MMS-F-ABORT, For target all, CLI returned abort status: %X10EE8034.

caused by a missing comma. Finally, all goes as planned until the library is to be created:

library/crea LAPACK_LIB:liblapack.olb dlamch.obj,dsecnd_INT_CPU_TIME.obj, ilaver.obj,lsame.obj,second_INT_CPU_TIME.obj, slam
ch.obj, LAPACK_version.obj, LAPACK_version.obj, tstiee.obj
%LIBRAR-W-OPENIN, error opening LAPACK_VMS:[000000.INSTALL]dlamch.obj; as input
-RMS-E-FNF, file not found
%LIBRAR-W-OPENIN, error opening LAPACK_VMS:[000000.INSTALL]dsecnd_INT_CPU_TIME.obj; as input
-RMS-E-FNF, file not found
%LIBRAR-W-OPENIN, error opening LAPACK_VMS:[000000.INSTALL]ilaver.obj; as input
-RMS-E-FNF, file not found
%LIBRAR-W-OPENIN, error opening LAPACK_VMS:[000000.INSTALL]lsame.obj; as input
-RMS-E-FNF, file not found
%LIBRAR-W-OPENIN, error opening LAPACK_VMS:[000000.INSTALL]second_INT_CPU_TIME.obj; as input
-RMS-E-FNF, file not found
%LIBRAR-W-OPENIN, error opening LAPACK_VMS:[000000.INSTALL]slamch.obj; as input
-RMS-E-FNF, file not found
%LIBRAR-W-OPENIN, error opening LAPACK_VMS:[000000.INSTALL]LAPACK_version.obj; as input
-RMS-E-FNF, file not found
%LIBRAR-W-OPENIN, error opening LAPACK_VMS:[000000.INSTALL]LAPACK_version.obj; as input
-RMS-E-FNF, file not found
%LIBRAR-W-OPENIN, error opening LAPACK_VMS:[000000.INSTALL]tstiee.obj; as input
-RMS-E-FNF, file not found
%MMS-F-ABORT, For target liblapack.olb, CLI returned abort status: %X10861098.
%MMS-F-ABORT, For target all, CLI returned abort status: %X10EE8034.
$

That is to be expected if the wrong directory-logical is used. It must be LAPACK_OBJ:

liblapack.olb : $(OBJS)
library/crea LAPACK_LIB:liblapack.olb LAPACK_OBJ:$(OBJS)
library LAPACK_LIB:liblapack.olb LAPACK_OBJ:$(OBJS64)

Changed that, but it is not sufficient:

library/crea LAPACK_LIB:liblapack.olb LAPACK_OBJ:dlamch.obj,dsecnd_INT_CPU_TIME.obj, ilaver.obj,lsame.obj,second_INT_CPU_TIME.obj
, slamch.obj, LAPACK_version.obj, LAPACK_version.obj, tstiee.obj
library LAPACK_LIB:liblapack.olb LAPACK_OBJ:dlamch_64.obj,dsecnd_INT_CPU_TIME_64.obj, ilaver_64.obj,lsame_64.obj,second_INT_CPU_TI
ME_64.obj, slamch_64.obj, LAPACK_version_64.obj, tstiee_64.obj
%LIBRAR-E-DUPGLOBAL, global symbol lapack_version from file LAPACK_VMS:[OBJ]LAPACK_version_64.obj;6 already in library LAPACK_VMS:[LIB]liblapack.olb;1
%LIBRAR-E-DUPGLOBAL, global symbol tstiee from file LAPACK_VMS:[OBJ]tstiee_64.obj;4 already in library LAPACK_VMS:[LIB]liblapack.olb;1
%MMS-F-ABORT, For target liblapack.olb, CLI returned abort status: %X108680B2.
%MMS-F-ABORT, For target all, CLI returned abort status: %X10EE8034.
$

Does this mean: Remove library and redo? no – the symbol is created in both the standard (32-bit) as 64-bit versions of these objects. Question is if these must be added in the library: these will be linked into executables and so are not to be added here: If done, first link fails:

LAPACK_version.exe : LAPACK_version.obj liblapack.olb
link/exec=LAPACK_EXE: LAPACK_OBJ:LAPACK_version.obj,LAPACK_LIB:Liblapack.olb/lib

results in

link/exec=LAPACK_EXE: LAPACK_OBJ:LAPACK_version.obj,LAPACK_LIB:Liblapack.olb/lib
%MMS-F-GWKNOPRN, There are no known sources for the current target Liblapack.olb
%MMS-F-ABORT, For target all, CLI returned abort status: %X10EE8064.

Minor adaptations to helper program required. But how….

So adapt VMS_autu64.for: Remove the directory from the name of the mapfile (which is input from commandline) and use what’s left to add to the line: scan this name from back to fron to “:” or “]”, or beginning. If not at beginning,take the part that was scanned (leaving what’s in front alone), otherwise use the string.
It’s a matter of getting used to Fortran after so many years, especially where it is Fortran90 (not FORTRAN77)

Back to basics – and create a logical environment, LAPACK first

Adapting makefiles is a huge undertaking, and not without problems because of nesting.
So fall back on ‘basic’ compilation – but it seems OpenBLAS may nog include all subprojects. the 3.8.0 version of LAPACK taken from GitHub contains LAPACK, BLAS and LAPACKE/ It may be sufficient to use these in stead of what is included in OpenBLAS, at least it is possible te refer to libraries on different locations.
So use the lasts LAPACK (and therefore BLAS) version, add the adaptions of Jouk Jansen in directory [.VMS] and define logicals referring this one before the base ones. Also split the output: .OBJ files into [.OBJ], list- and mapfiles in [.LIS], libarties in [.LIB] and executables in [.EXE]/ Because Jouk Jansen’s procedure puts all files in [.SRC]. be it, in this configuration, the ones in the [.VMS] structure. But it is (in my opinion) a bad habit….
It means the MMS files need to be adapted so the results are put into the right location.

Created procedure SetETW.com that sets the required logicals, and these must be mentioned in the MMS files. This means adaptation but (hopelfully) straight forward. First part is the [.INSTALL] environment: but here something fails in FORTRAN files that are to contain the 64-bit versions, compiled with C: the directory is added – and the right name is truncated:

$ mms

cc/define=(VMS)/comment=as_is/prep=LAPACK_INS:LAPACK_version.f_ LAPACK_INS:LAPACK_version.f
fortran/name=lower/float=ieee/ieee=denorm/list=LAPACK_LIS:/show=all/obj=LAPACK_OBJ:LAPACK_version.obj LAPACK_INS:LAPACK_version.f_
pipe link/map=LAPACK_LIS:/full/exec=nl: LAPACK_OBJ:LAPACK_version | copy sys$input nl:
mc etwexe:vms_auto64 LAPACK_LIS:LAPACK_version.map LAPACK_LIS:LAPACK_version.lis
normal end
cc/define=(VMS)/comment=as_is/prep=LAPACK_INS:LAPACK_version_64.f_ LAPACK_INS:LAPACK_version_64.f
fortran/name=lower/float=ieee/ieee=denorm/obj=LAPACK_OBJ:LAPACK_version_64.obj LAPACK_INS:LAPACK_version_64.f_

subroutine dummy__LAPACK_LIS:LAPA0940_64__
....................................^
%F90-E-ERROR, Syntax error, found IDENTIFIER 'LAPA0940_64__' when expecting one of: DO FORALL SELECT SELECTCASE WHERE IF
at line number 1 in file LAPACK_VMS:[INSTALL]LAPACK_version_64.f;3

subroutine dummy__LAPACK_LIS:LAPA0940_64__
^
%F90-E-ERROR, An unterminated block exists.
at line number 1 in file LAPACK_VMS:[INSTALL]LAPACK_version_64.f;3
%MMS-F-ABORT, For target LAPACK_version.obj, CLI returned abort status: %X186A1262.
$

The file starts:

subroutine dummy__LAPACK_LIS:LAPA0940_64__
end
# 1 "LAPACK_VMS:[INSTALL]LAPACK_version.f;1"
*> \brief \b LAPACK_VERSION

and these lines are added by:

mc etwexe:vms_auto64 LAPACK_LIS:$(MMS$TARGET_NAME).map LAPACK_LIS:$(MMS$TARGET_NAME).lis

or is this in line:

cc/define=(VMS)/comment=as_is/prep=LAPACK_INS:$(MMS$TARGET_NAME).f_\
LAPACK_INS:$(MMS$TARGET_NAME).f

No: it is vms_auto64, the other creates the .f_ file but that is correct. So vms_aut064 must be examined, it should use just the filename. Another option is to leave the 64-bit files out of compilations – for now

New additions fromTU Delft don’t help on OpenBLAS’s LAPACK

New versions of VMS patches by TU Delft: do OpenBLAS first, in principle can be done using MMS but makefile needs to be adapted first so the statement that cannot be handled (and are not accessed) are bypassed by adding:

ifneq($(OSNAME), VMS)

what should disable the part beyond this until according endif. But for some reason it didn’t work: MMS fails on

ifndef

SciPy 13-Jul-2019

NIEUW: VSI has released VMSIDE on to op Microsoft’s VisualStudioCode. So installed both – and added VMS_DCL in to mix. But this does’t work nicely: base code needs to be on PC, nor is structure feasible, because each part with a project is a project in itself (BLAS, being part of LAPACK, needs to be a project in itself, bound under LAPACK), as is shown in the instruction Video. Not really usable for existing projects. So for Numpy and OpenBLAS, it means a lot of extra work.

Needed to reload the versions of Numpy and OpenBLAS – were previously transferred ASCII in stead of BINARY.