Building XSLT under OpenVMS =========================== Here's a summary of the issues I encountered when building XSLT under VMS. I'd previously done the same for the LIBXML package, on which XSLT depends. I present this list "as is" to hopefully act as a guide to anyone having similar problems in the future. That's it. Good luck! John A Fotheringham (jaf@jafsoft.com) November 2001 Installation kit ---------------- - File attributes. When downloading essentially a Unix distribution, some of the file attributes may not be correct... especially those in the [.VMS] subdirectory. In EDT you could see line feeds and carriage returns as etc. To correct this use the command $ set file /attr=rfm=stm This sets the record format to be "stream". Other variants may be used instead depending on how you got the files onto your system. Files will look okay in an EDT editor once the attributes are set. Without this the command file may not run correctly, since it may be interpreted as a single line. - VMS-specific files are in a [.VMS] directory. If you've found this file then you already know this :-) This directory contains BUILD_XSLT.COM - a build command file README.VMS - these notes - Don't execute BUILD_LIBXML.COM until you've done all the following - read these notes - define the logicals XMLOLB and LIBXML - copy CONFIG.H to [.libxslt] and [.libexslt] - reviewed the configuration section of BUILD_XSLT.COM, and in particular update the module lists in line with MAKEFILE - re-read these notes :-p instructions for all these steps are below. - the XSLT package requires the LIBXML package to have been previously been installed. The following logicals should be defined LIBXML - the directory containing LIBXML's .h files XMLOLB - the directory to contain both the LIBXML and XSLT object libraries - you'll need to copy config.h into the [.libxslt] and [.libexslt] directories. If in the future a VMS-specific version is created, use [.vms]config.vms instead. - The command file BUILD_XSLT.COM will do the following - setup and test some logicals - set def to the source directory - compile modules and place them into a LIBXSLT.OLB library - compile modules and place them into a LIBEZSLT.OLB library - compile and link the XSLTPROC program - set def back to the original directory (i.e. if it fails you might not be where you started :-) before running this command file review the configuration segment at the top. In particular compare the lists of modules with those in the most recent version of MAKEFILE.IN files sound in the source directories. Instructions are contained in the command file itself. The TRIO package ---------------- - The libxml package uses a sub-package TRIO to provide some functions not naturally available under VMS. These include support for infinite and undefined numbers, and specialised print functions like "snprintf" To build this software we need to add /IEEE_MODE=UNDERFLOW_TO_ZERO/FLOAT=IEEE to the compile command for xsltutils, and to any main program that uses this functionality. BUILD_XSLT.COM should do this for you. Without this you are likely to get run-time errors like this %SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00000 400, summary=02, PC=000000000006A330, PS=0000001B -SYSTEM-F-FLTINV, floating invalid operation, PC=000000000006A330, PS=0000001B If this occurs you'll need to locate the modules that need the above switches applied Compiler and linker errors -------------------------- - with respect to the TRIO package you'll get the error "no main module for UNDERFLOW_TO_ZERO" You can suppress this "expected" messages by using the compile command $ CC /WARN=DISABLE=(NOMAINUFLO) - the Linker will report the following error %LINK-W-MULDEF, symbol DECC$STRERROR multiply defined in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;5 This is complaining that DECC$STRERROR is multiply defined, which in turn is because this system symbol is getting added to LIBXML.OLB when strio.c was compiled in the libxml package. I'm not sure what the solution for this is, but this is a fairly benign error. Changes made to the codebase ---------------------------- - In the module extensions.c the name xsltExtModuleElementPreComputeLookup is too long (more than 31 characters). The solution has been to rename it to a shorter name on VMS builds, and to then create a #define that maps the longer name to the shorter name, so that all references to the longer name will work. You may need to repeat this exercise with any future modules added.