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.

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

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

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.