Back again, after a major hard drive failure taught me an important lesson about making backups...
Before updating zlib to the latest version, I wanted to build from source, with tuning optimisations enabled.
Optimising zlib was achieved editing make_vms.com
-- ccopt3 = '/opt=(inline'
++ ccopt3='/opt=(tune=host,inline=speed)
Installation of the updated images required renaming of two files prior to running install_libz_gnv.com
libzshr.exe to gnv$libzshr.exe
gnv_zlib_startup.com to gnv$zlib_startup.com
Then run install_libz_gnv.com to copy the files into the right GNV directories.
Building OpenSource on OpenVMS Blog
This blog serves as a record of my attempts to build various software packages on OpenVMS Alpha. The aim is to get the original CSWB source to build, so I can then update the source to a new version of SeaMonkey...
Sunday, 2 June 2019
Tuesday, 16 April 2019
SWB Source Setup
In an earlier post I reproduced the full description from the defunct HP website about how to recompile SWB. Some of it is clearly outdated and doesn't relate to the current version of the SWB. It's noticeable that the text is identical to the text that was on an earlier version of the HP website for recompiling v1.7.13 including comments about fixes to configure required for v1.7.
For example, examining the SWB source it was obvious that the section titled "Setting up Configure" is not required (the patching done by sed is already in the source code).
The "Running Configure (non-debug)" section was executed with a minor change that I don't know what the libvmscxx.so file is that is supposed to be copied from work:[work.cxx] but it isn't supplied with the SWB source. So instead I create an empty equivalent via:
$ library/alpha/share create libvmscxx.so
I think this is related to the -lvmscxx compiler switch that I had to remove as it caused the configure script to fail.
I also chose not to copy over bash.rc as it creates a very customised GNV installation that breaks compilation of a lot of other stuff due to the many includes. Instead I just manually copy+paste the bash.rc contents at the bash prompt when I am working with SWB.
For example, examining the SWB source it was obvious that the section titled "Setting up Configure" is not required (the patching done by sed is already in the source code).
The "Running Configure (non-debug)" section was executed with a minor change that I don't know what the libvmscxx.so file is that is supposed to be copied from work:[work.cxx] but it isn't supplied with the SWB source. So instead I create an empty equivalent via:
$ library/alpha/share create libvmscxx.so
I think this is related to the -lvmscxx compiler switch that I had to remove as it caused the configure script to fail.
I also chose not to copy over bash.rc as it creates a very customised GNV installation that breaks compilation of a lot of other stuff due to the many includes. Instead I just manually copy+paste the bash.rc contents at the bash prompt when I am working with SWB.
Saturday, 13 April 2019
Updating other GNV utilities
I re-compiled the rest of the GNV utilities (make, coreutils, etc), partly to enable architecture specific optimisations, and also to see if any wouldn't recompile straight away. This also enabled me to be setup should I want to attempt to compile newer versions. Results were as follows:
Re-compiled with no issues:
bash
sed
make
coreutils
diffutils
grep
vmstar
unzip
Recompiled after minor modification:
ncompress
- error when [.vms]pcsi_product_ncompress.com is first run, requires modification to [build.ncompress]Makefile to replace `date` with an actual date (e.g. 10-APR-2019) and then running [.vms]pcsi_product_ncompress.com again.
Wouldn't recompile:
bzip2 - some kind of #pragma error that I haven't debugged yet
Re-compiled with no issues:
bash
sed
make
coreutils
diffutils
grep
vmstar
unzip
Recompiled after minor modification:
ncompress
- error when [.vms]pcsi_product_ncompress.com is first run, requires modification to [build.ncompress]Makefile to replace `date` with an actual date (e.g. 10-APR-2019) and then running [.vms]pcsi_product_ncompress.com again.
Wouldn't recompile:
bzip2 - some kind of #pragma error that I haven't debugged yet
Friday, 12 April 2019
Updating sed
This was also straight-forward to re-compile. For some reason the original version when installed from the downloaded PCSI wouldn't create Makefiles when ever a script tried to use it. I spent ages trying to work out what was causing configure. scripts to fail, usually with something along the lines of:
sed %s %s unable to ...
Once I'd recompiled and installed (the same version of) sed, the problem went away.
Recompilation was
$ set def gnv$gnu:[000000]
$ @[build]build.com
directory: sed
$ set def PRJ_ROOT:[sed]
$ @[.vms]pcsi_product_sed.com
I replaced /debu and /debug with /opt=(tune=host) in sed.mms before recompiling. This leaves me with an optimised version of sed 4.2.2
Wednesday, 10 April 2019
Updating bash
Once I'd successfully recompiled bash 4.3.46 (see previous post), I then took the relatively simple step of updating bash to 4.3.48.
Recompiling bash 4.3.46 was as follows:
$ set def gnv$gnu:[000000]
$ @[build]bash.com
directory: bash
$ set def PRJ_ROOT:[bash]
$ @clean_bash.com realclean
$ @build_bash.com
$ @remove_old_bash.com
$ @stage_bash_install.com
$ @pcsi_product_gnv_bash.com
I had already modified bash.mms to remove /debu from the cflags and cflagsx definitions, and replaced them with /opt=(tune=host)
The final script creates a PCSI installation file in the STAGE_ROOT:[KIT] area.
Once I'd verified that bash had recompiled correctly, I downloaded bash 4.3.48 into the gnv$gnu:[common_src.bash] folder and compiled as per before; this produced bash 4.3.48.
I sometimes find that the old version of bash isn't removed and replaced with the new version, even after running the scripts above. So I sometimes just delete the bash. and bash.exe from gnu:[bin] and then run stage_bash_install.com to copy the new version over.
On a previous occasion, I manually edited the source from 4.3.46 based on the 4.3.47 and 4.3.48 patch changes. This is not a recommended approach, but it did mean I could understand what the patches did.
Recompiling bash 4.3.46 was as follows:
$ set def gnv$gnu:[000000]
$ @[build]bash.com
directory: bash
$ set def PRJ_ROOT:[bash]
$ @clean_bash.com realclean
$ @build_bash.com
$ @remove_old_bash.com
$ @stage_bash_install.com
$ @pcsi_product_gnv_bash.com
I had already modified bash.mms to remove /debu from the cflags and cflagsx definitions, and replaced them with /opt=(tune=host)
The final script creates a PCSI installation file in the STAGE_ROOT:[KIT] area.
Once I'd verified that bash had recompiled correctly, I downloaded bash 4.3.48 into the gnv$gnu:[common_src.bash] folder and compiled as per before; this produced bash 4.3.48.
I sometimes find that the old version of bash isn't removed and replaced with the new version, even after running the scripts above. So I sometimes just delete the bash. and bash.exe from gnu:[bin] and then run stage_bash_install.com to copy the new version over.
On a previous occasion, I manually edited the source from 4.3.46 based on the 4.3.47 and 4.3.48 patch changes. This is not a recommended approach, but it did mean I could understand what the patches did.
Wednesday, 27 March 2019
Compiling GNV programs
Before I started on updating the GNV utilities to newer versions, I needed to demonstrate that I could compile the existing ones from source. Having installed the source when installing the apps (by choosing not to select default installation options), I was left with two directories in the GNV root folder, common_src which contains the untouched original GNU source, and vms_src which contains vms specific files. I also created a gnv$gnu:[build] directory in which the recompiled software would be built.
The main GNV utilities are well documented by JEM and include pretty much everything you need to know to recompile them. I followed the supplied instructions and successfully recompiled the utilities without any major hitches. I created a following script setup.com in the gnv$gnu:[build] directory to expedite the setting up of logicals for each compilation:
read/prompt="directory: " sys$command file
DEFINE/TRANS=CONC VMS_ROOT DKA0:[SYS0.SYSCOMMON.GNV.VMS_SRC.'file'.]
DEFINE/TRANS=CONC SRC_ROOT DKA0:[SYS0.SYSCOMMON.GNV.COMMON_SRC.'file'.]
DEFINE/TRANS=CONC LCL_ROOT DKA0:[SYS0.SYSCOMMON.GNV.BUILD.'file'.]
DEFINE REF_ROOT VMS_ROOT:,SRC_ROOT:
DEFINE PRJ_ROOT LCL_ROOT:, REF_ROOT:
set def PRJ_ROOT:[000000]
DEFINE GNV_PCSI_PRODUCER "JEM"
DEFINE GNV_PCSI_PRODUCER_FULL_NAME "JEM"
DEFINE STAGE_ROOT/TRANS=CONC DKA0:[SYS0.SYSCOMMON.GNV.BUILD.]
DEFINE NEW_GNU GNV$GNU:
This script prompts for the name of the utility that is to be recompiled, sets the logicals, and then set the default directory to the prj_root. I normally then follow this with a set def prj_root:[xxx] command, where xxx is the name of the folder shown from the directory listings (for the GNV utilities it's usually just the name of the utility, but for the other libraries like libpng it is a combination of the name and the version number). I've not changed the producer name yet because keeping the JEM ensures that any other programs that have a dependency on these utilities will still work.
The first time this is done, it is also necessary to recreate empty copies of any directories in the common_src and vms_src directories, in the build directory:
$ copy SRC_ROOT:[000000...]*.dir;* LCL_ROOT:[000000...]*.dir;*
$ copy VMS_ROOT:[000000...]*.dir;* LCL_ROOT:[000000...]*.dir;*
I also created a directory gnv$gnu:[build.kit] that will store all the new PCSI install files.
Compiling the utilities should then just be a case of running the right .COM file - the names seem to be slightly different for each utility, e.g. build_bash.com, pcsi_product_sed.com
It's a good idea to run the included "clean" scripts e.g. clean_bash.com first to clear out any residual files, compiler failures were often traced back to this.
Most of the build scripts have debugging enabled, I disabled this by deleting the /debu qualifier from the descrip.mms makefile.
Installation of the re-compiled executables requires deleting the original executable - the installer seems to refuse to install over any existing executables. Some of the utilities include a script to do this e.g. remove_bash.com
The main GNV utilities are well documented by JEM and include pretty much everything you need to know to recompile them. I followed the supplied instructions and successfully recompiled the utilities without any major hitches. I created a following script setup.com in the gnv$gnu:[build] directory to expedite the setting up of logicals for each compilation:
read/prompt="directory: " sys$command file
DEFINE/TRANS=CONC VMS_ROOT DKA0:[SYS0.SYSCOMMON.GNV.VMS_SRC.'file'.]
DEFINE/TRANS=CONC SRC_ROOT DKA0:[SYS0.SYSCOMMON.GNV.COMMON_SRC.'file'.]
DEFINE/TRANS=CONC LCL_ROOT DKA0:[SYS0.SYSCOMMON.GNV.BUILD.'file'.]
DEFINE REF_ROOT VMS_ROOT:,SRC_ROOT:
DEFINE PRJ_ROOT LCL_ROOT:, REF_ROOT:
set def PRJ_ROOT:[000000]
DEFINE GNV_PCSI_PRODUCER "JEM"
DEFINE GNV_PCSI_PRODUCER_FULL_NAME "JEM"
DEFINE STAGE_ROOT/TRANS=CONC DKA0:[SYS0.SYSCOMMON.GNV.BUILD.]
DEFINE NEW_GNU GNV$GNU:
This script prompts for the name of the utility that is to be recompiled, sets the logicals, and then set the default directory to the prj_root. I normally then follow this with a set def prj_root:[xxx] command, where xxx is the name of the folder shown from the directory listings (for the GNV utilities it's usually just the name of the utility, but for the other libraries like libpng it is a combination of the name and the version number). I've not changed the producer name yet because keeping the JEM ensures that any other programs that have a dependency on these utilities will still work.
The first time this is done, it is also necessary to recreate empty copies of any directories in the common_src and vms_src directories, in the build directory:
$ copy SRC_ROOT:[000000...]*.dir;* LCL_ROOT:[000000...]*.dir;*
$ copy VMS_ROOT:[000000...]*.dir;* LCL_ROOT:[000000...]*.dir;*
I also created a directory gnv$gnu:[build.kit] that will store all the new PCSI install files.
Compiling the utilities should then just be a case of running the right .COM file - the names seem to be slightly different for each utility, e.g. build_bash.com, pcsi_product_sed.com
It's a good idea to run the included "clean" scripts e.g. clean_bash.com first to clear out any residual files, compiler failures were often traced back to this.
Most of the build scripts have debugging enabled, I disabled this by deleting the /debu qualifier from the descrip.mms makefile.
Installation of the re-compiled executables requires deleting the original executable - the installer seems to refuse to install over any existing executables. Some of the utilities include a script to do this e.g. remove_bash.com
Monday, 25 March 2019
Books
Sadly, I had to leave behind my copy of the infamous 32-binder DEC wall of reference books when I moved countries so I am reliant on PDF versions downloaded from HP and VSI. It's never the same as having a real book, even if they are much easier to search!
I'm also slowly building up my collection of other (physical) OpenVMS related books as I find them for reasonable second-hand prices, so far I have:
UNIX for OpenVMS Users
Publisher: Digital Press; 3rd Edition (May 2, 2003)
ISBN-10: 1555582761
Getting Started with OpenVMS: A Guide for New Users
Publisher: Digital Press; 1st Edition (November 27, 2002)
ISBN-10: 1555582796
OpenVMS with Apache, WASD, and OSU: The Nonstop Webserver
Publisher: Digital Press; 1st Edition (October 24, 2002)
ISBN-10: 1555582648
Linux and OpenVMS Interoperability
Digital Press; 1st Edition (April 15, 2003)
ISBN-10: 1555582672
OpenVMS System Management Guide
Publisher: Digital Press; 2nd Edition (November 7, 2003)
ISBN-10: 1555582435
OpenVMS AXP Internals and Data Structures, Version 1.5
Publisher: Digital Press; (January 15, 1994)
ISBN-10: 155558120X
OpenVMS Alpha Internals and Data Structures: Memory Management
Digital Press; 1st Edition (December 6, 2002)
ISBN-10: 1555581595
OpenVMS Alpha Internals and Data Structures: Scheduling and Process Control
Publisher: Digital Press; 1st Edition (January 9, 1997)
ISBN-10: 1555581560
Getting Started with OpenVMS System Management
Publisher: Digital Press; 1st Edition (April 15, 2003)
ISBN-10: 1555582818
I'm also slowly building up my collection of other (physical) OpenVMS related books as I find them for reasonable second-hand prices, so far I have:
UNIX for OpenVMS Users
Publisher: Digital Press; 3rd Edition (May 2, 2003)
ISBN-10: 1555582761
Getting Started with OpenVMS: A Guide for New Users
Publisher: Digital Press; 1st Edition (November 27, 2002)
ISBN-10: 1555582796
OpenVMS with Apache, WASD, and OSU: The Nonstop Webserver
Publisher: Digital Press; 1st Edition (October 24, 2002)
ISBN-10: 1555582648
Linux and OpenVMS Interoperability
Digital Press; 1st Edition (April 15, 2003)
ISBN-10: 1555582672
OpenVMS System Management Guide
Publisher: Digital Press; 2nd Edition (November 7, 2003)
ISBN-10: 1555582435
OpenVMS AXP Internals and Data Structures, Version 1.5
Publisher: Digital Press; (January 15, 1994)
ISBN-10: 155558120X
OpenVMS Alpha Internals and Data Structures: Memory Management
Digital Press; 1st Edition (December 6, 2002)
ISBN-10: 1555581595
OpenVMS Alpha Internals and Data Structures: Scheduling and Process Control
Publisher: Digital Press; 1st Edition (January 9, 1997)
ISBN-10: 1555581560
Getting Started with OpenVMS System Management
Publisher: Digital Press; 1st Edition (April 15, 2003)
ISBN-10: 1555582818
Writing OpenVMS Alpha Device Drivers in C: Developer's Guide and Reference Manual
Publisher: Digital Press; 1st Edition (1 Sept 1996)
Publisher: Digital Press; 1st Edition (1 Sept 1996)
ISBN-10: 1555581331
Using DECWindows MOTIF for OpenVMS
Publisher: Digital Press; 1st Edition (1993)
ISBN-10: 155581145
Alpha Architecture Reference Manual
Publisher: Digital Press; 1st Edition (1992)
ISBN-10: 155558098
I'm aware of, and watching for this book:
Writing OpenVMS Alpha Device Drivers in C: Developer's Guide and Reference Manual
Publisher: Digital Press; 2nd Edition (1 July 1999)
ISBN-10: 1555582095
Writing OpenVMS Alpha Device Drivers in C: Developer's Guide and Reference Manual
Publisher: Digital Press; 2nd Edition (1 July 1999)
ISBN-10: 1555582095
Subscribe to:
Posts (Atom)