GNU for VMS Wiki

GNV Provides a Framework for Porting Open Source Software to OpenVMS

Brought to you by: billpedersen, hp-gnv-devlp, is014, johnreagan, and 2 others

InstallingGNVPackages

Authors:

Installing the new GNV packages

You should read these general instructions completely before installing the new GNV packages.

On Alpha and IA64 the GNV packages must be installed on an ODS-5 volume.

Some or all of the GNV base packages do not properly install off the system disk. As I have stopped personally installing the GNV base packages any more, I have not been tracking what is working in the GNV base kits and what is not.

At this time, base GNV kit is no longer needed for building most open source projects, but if you want to install it anyway, it must be installed first.
I have not installed the latest GNV base kits on any of my systems, but have an older GNV 2.1.3 on just one of my systems.

People have reported various problems with installing the latest and some of the earlier GNV base kits.

While the base kits have some more utilities than are available in separate packages, they are usually not used in Open Source projects.

If you still want to install the base kits, you have been warned that there are issues.

We are updating the GNV project and transitioning GNV to be a set of kits that the GNV package will install. During this transition some extra issues will need to be handled during installs and upgrades.

If you are installing or upgrading the base GNV kit, you must install it first and then install the updated kits. The GNV base kit will otherwise attempt to replace the newer files with older ones.

The install or upgrade of the base GNV kit will probably delete the entire contents of the GNV directory tree when you install it, so make sure that you have backed up any additions that you have made. It may also rename the directory tree to allow you to recover your files easier, or to surprise you when you find a bunc of extra files.

The above actions will cause errors when trying to reinstall the updated GNV components that are in separate kits and you will need to say "YES" to continue to work around them.

If you have GNV 2.1.3 already installed, just installing the updated components will work to allow you to run most configure and the make files generated by it.

It you are upgrading or have updated the base GNV kit, you need to inspect your installation disk. The GNV 2.13 and 3.0.* kits as part of their startup procedure creates a PSX$ROOT and places the files there. It then mounts the
[vms$common.gnv] directory as "/" on the PSX$ROOT.

This potentially creates several problems where the [vms$common.gnv] does not get mounted you could end up with different files in PSX$ROOT:[000000] and [vms$common.gnv]. So before upgrade, unless you have already modified the GNV startup procedure to not mount [vms$common.gnv] to mount the [vms$common.vms]*.dir on psx$root:[000000]*.dir, you should use the "mcr [vms$common.gnv]umnt \/" to remove the mount point. Then delete all the files under [vms$common.gnv...] and if there are any GNV files under psx$root:[000000] after the unmount, then delete them also. This information is also repeated in more detail later in the document.

The current base GNV kits are:
OpenVMS Alpha: DEC-AXPVMS-GNV-V0300-001-1.ZIP
OpenVMS I64 V8.4 or earlier: HP-I64VMS-GNV-V0300-001-1.ZIP
OpenVMS I64 V8.4-1H1 or later: VSI-I64VMS-GNV-V0300-002-1.ZIP

There are reports that the signatures on the base GNV kit do not verify. Use the /options=(novalidate_kit) to work around this.

The updated kits are at the time this article was last updated are for OpenVMS/Alpha 8.3+ and OpenVMS/IA4 8.4+.
Each kit is in its own directory.

As new packages may be added with out updating this wiki, see Files for the current list.

All new GNV packages except some UNZIP binaries are in zipped PCSI packages. The files that are just in .ZIP archives are not really part of GNV.

Do not go by the dates on the packages, these may not be accurate due to site reorganizations.

ar_tools AR simulation tools
bash
bzip2
coreutils
diffutils
gawk
grep
ld_tools CC/LD/C++/CPP simulation tools.
make
ncompress
sed
vmstar
zip and unzip

There is also an Others directory. This is not really part of the GNV project, just some files someone at one time thought would be helpful.

As far as I know, the contents of the these three directories came from either DEC, HP, OR VSI.:
The GNV_- I64 contains the IA64 base kits including older versions.
The GNV - Alpha contains the Alpha base kit including older versions, and for some unknown reason the Alpha GNV V3.0.1 directory currently contains a very old and out of date BASH kit.
The GNV contains what appears to be a pre-release test version of GNV for Alpha.

Some of these packages were previously created with different producer prefixes. We are standardizing on VMSPORTS and GNV as the producer prefixes for community supplied images.. GNV will be for packages that are part of the GNV product suite, and VMSPORTS will be for most other packages.

Due to the way that PCSI identifies packages, if you install a package from one producer prefix and then want to upgrade it from another producer, you will need to uninstall the previous package first.

This uninstall can cause warning messages about dependencies. If you are transitioning to an upwardly compatible package, you can ignore those warnings.

The new GNV packages should be installed to the same volume as GNV is installed.

The new GNV packages such as for Bash and Coreutils have startup procedures in [vms$common.sys$startup] that define a logical name GNV$GNU for locating the binaries. The older GNV packages used the logical name GNU which violates the OpenVMS coding standards for package supplied system logical names. If gnv$gnu is not defined on your system then it means that the installation procedure has not been run.

Again, as a reminder, If you uninstall or upgrade the existing GNV package or install the GNV package from before the transition is complete, you will need to reinstall all other packages that install to the same GNV directory tree. This is because at least some of the existing GNV installation procedures have a bug in them. where instead of just deleting the files that were installed, they delete all files in the GNV directory tree.

Because this is a transition, these new packages are replacing files from the old GNV packages. This is a necessary issue to allow incremental improvement as we can not replace the GNV package with the new format until we get all the component packages done.

Sometimes the replacement fails. This can happen when there are multiple versions of a file in the directory. With the new kits where this is a possibility, there will usually be files command files installed in the gnv$gnu:[vms_bin] directory that can be used to remove the files from the old kits.

The new packages use images that are prefixed with gnv$ and then create either scripts, hardlinks, or symbolic links to the name of the files expected by shell scripts. If the replacement above failed, there will usually be files in gnv$gnu:[vms_bin] that will recreate the aliases.

The GNV 2. through at least the 3.0. kits make an unusual change to the disk directory structure where they are installed where they use the [vms$common.gnv] as a mount point and mount the posix root on it. This is a bug because it causes many problems and does not offer any advantages. One of the problems is that it causes problems with other PCSI installs and uninstalls to that directory.

Update, symbolic links should be used instead of mount points. That also removes needing to have a startup script re-apply the mounts. I have not had time to detail the procedure that replaces the text below.

An advanced user can repair the directory organization bug. On encompasserve.org this has been done as documented in Reply 12 of the GNV GNU on VMS topic the VMS notes conference.
It involves un-mounting the psx$root: from the [vms$common.gnv] directory, renaming the directories in psx$root:[000000] back to [vms$common.gnv], and then modifying the psx$up_startup.com and gnv$startup.com to mount the directories on psx$root:[000000]*.dir.

Because of the directory change bug, a gnv$startup.com or gnv_startup.com in the GNV kit must be run when the system boots up or the [vms$common.gnv]directory will appear to be empty.

If a PCSI kit like this one is installed when the GNV startup has not been run, it will create a new directory tree under [vms$common.gnv] that will not be visible to the posix root. If you uninstall this PCSI kit before running the gnv$startup.com procedure then you can install it after running the gnv$startup.com procedure. If you have run the gnv$startup.com procedure after the install, then you have a mess, and you will need to use the GNV umnt to un-mount the [vms$common.gnv] directory before the uninstall of this kit will work. See the Mount Points Wiki article article for more details on mount points and how to clean up problems with them.

An analyze/disk/repair step on the installation disk should be done after installation to collect files left over from incomplete deletions into the [SYSLOST] directory. This step should be done on a "quiet" system per HP recommendations.