Re: [xml] LIBXML2/LIBXSLT build problems on VMS

[Daniel Veillard <veillard redhat com>]

On Tue, Dec 17, 2002 at 11:04:57PM -0600, Craig A. Berry wrote:
> At 3:40 PM +0000 12/17/02, Nigel Hall wrote:
> > Below are the problems I found building LIBXML2 and LIBXSLT on VMS recently.
>
> Please state compiler, operating system, and package versions, as
> well as verbatim error messages when reporting a problem.  Actually I
> think you did say earlier in the thread that the package version was
> libxml2 2.4.28?
>
> > LIBXML2
> > ~~~~~~
> > Compile of TREE.C failed with errors about cur parameter on these lines:
> >    htmlSetMetaEncoding(cur, (const xmlChar *) encoding);
> >    htmlSetMetaEncoding(cur, BAD_CAST "UTF-8");
> > Changed them to use doc parameter instead, like this:
> >    htmlSetMetaEncoding(doc, (const xmlChar *) encoding);
> >    htmlSetMetaEncoding(doc, BAD_CAST "UTF-8");
>
>
> I can't reproduce this using Compaq C 6.5 on OpenVMS Alpha 7.3-1
> building libxml2 2.4.30.

  Looking at it, the recent versions do
    htmlSetMetaEncoding((htmlDocPtr) cur,
but I wonder how much of a bug it is. I will switch to 
    htmlSetMetaEncoding((htmlDocPtr) doc,
in xmlNodeDumpOutput() (not xmlDocContentDumpOutput())

> > Compile of TRIO.C failed on lines containing TRIO_VA_START(args, format)
> > with unexpected identifier.
> > Changed the following line in TRIODEF.H from:
> >    # define TRIO_VA_START(x,y) va_start((x),(y))
> > to:
> >    # define TRIO_VA_START(x,y) va_start(x,y)
>
>
> Yeah.  Someone else on comp.os.vms also reported this.  What I said
> about it there was, "This appears to have been an overzealous reading
> of the C standard by the compiler group.  The standard says the 2nd
> arg to va_start is an identifier, and they decided that an identifier
> enclosed in parens is not an identifier."  The problem does not occur
> in DEC/Compaq C 6.4 or 6.5.  DEC/Compaq C 6.2 and earlier do appear
> to have the problem.  I don't know that I would suggest changing the
> code, but we should probably mention it in vms/readme.vms.

   Hum, the trio code is Bjorn Reese area of expertise, I prefer to not patch
in libxml2 directly, if there is a fix it should go upstream to the trio library
then I expect Bjorn will update libxml2.

> > Shortened function names for VMS 32 character limit:
> > in ATTRIBUTES.C from xsltResolveStylesheetAttributeSet to
> > xsltResolveStylesheetAttrSet
> > in TEMPLATES.C from xsltAttrTemplateValueProcessNode to
> > xsltAttrTemplateValueProcNode
>
> I can't reproduce this either, and since the build uses
> /NAMES=SHORTENED I'm skeptical that this is really the issue you are
> encountering.

   isn't the libxslt build using #define for long identifiers on
VMS like this was apparently suggested for libxml2 ?

> > LIBXSLT
> > ~~~~~~~
> > Added SECURITY.C to XSLT build script.
> > Added DYNAMIC.C to EXSLT build script.
>
> Sounds good.
>
> > In XSLTUTILS.C commented out the ifdefn for vsnprint, like this:
> >
> > //#ifdef XSLT_NEED_TRIO
> > #define vsnprintf trio_vsnprintf
> > //#endif
>
> What was the error message?  And how did you get C++ style comments
> to work with the C compiler?  If you were using the C++ compiler,
> clearly other modifications to the build procedures were necessary.
> Please state precise steps taken and compiler used.

   I would prefer #ifdef VMS style of patch

> > Changed build of LIBXSLT to use FLOAT=IEEE on all compiles and the same
> > IEEE_MODE as LIBXML2 (DENORM_RESULTS) to resolve run-time crash and
> > formatting problem in format-number function.
>
> That sounds reasonable.  I recently updated the build script for
> libxml2 but not for libxslt; I will try to get together a patch for
> the latter but it may be early in the new year before I get to it.

   Okay can you send a (couple of) contextual diff ?

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/