source: vbox/trunk/src/libs/libxslt-1.1.22/vms/readme.vms@ 12198

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 <LF><CR> etc.  To correct this use the command

        $ set file <filespec> /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.