libxslt upgrade breaks CentOS 5 build

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

libxslt upgrade breaks CentOS 5 build

Don Lewis-2
I've been looking at upgrading a bunch of our bundled dependencies, and
it looks like upgrading libxslt (or maybe libxml2) breaks the build on
CentOS 5.

The writerfilter module uses xsltproc to generate the header
resources.hxx, and in some cases it contains invalid C cod such as:
            return (getU32(744))>>;
whereas it should be:
            return (getU32(744));

The shift fragment of this expression comes from this xsl template:
            ...
            <xsl:if test="$shift>0">
              <xsl:text>&gt;&gt; </xsl:text>
              <xsl:value-of select="$shift"/>
            </xsl:if>
            <xsl:text>;</xsl:text>
If there is a nonzero shift, the it should output "foo>>shift;", and if
the shift amount is zero, then it should just output "foo;".

In the normal case, the input data looks like:
              <UML:ModelElement.taggedValue>
                <UML:TaggedValue>
                  <UML:TaggedValue.dataValue>0</UML:TaggedValue.dataValue>
                  <UML:TaggedValue.type>
                    <UML:TagDefinition xmi.idref="shift"/>
                  </UML:TaggedValue.type>
                </UML:TaggedValue>
              </UML:ModelElement.taggedValue>
for a shift amount of zero.  One example of the broken case it is:
              <UML:ModelElement.taggedValue>
                <UML:TaggedValue>
                  <UML:TaggedValue.dataValue/>
                  <UML:TaggedValue.type>
                    <UML:TagDefinition xmi.idref="shift"/>
                  </UML:TaggedValue.type>
                </UML:TaggedValue>
              </UML:ModelElement.taggedValue>
so the value is missing (the tag is self-closing in this case),
so presumably the if condition in the template is 'if test=">0"'. So
this input is looking pretty questionable.

The mystery is why this behaves differently on CentOS 5 vs. everywhere
else.  Only the resources.hxx header generated by CentOS 5 is broken.

One thing I noticed is that my CentOS 5 machine has system libxml and
libxslt libraries installed and they have the same library version
numbers as the ones we build.  My CentOS 6 machine does not.  The system
xsltproc generates a valid resources.hxx header.  One thought I had was
that the xsltproc that we build might be picking up the system
librariese and there was some subtle incompatiblity, but that does not
appear to be the case.  My other thought was some sort of compiler bug
triggered by the new code, but building the libxml2 and libxslt modules
with -O0 optimization did not change anything.

Probably the best fix is to modify the template to check for blank shift
values, but the mystery remains.

--- a/main/writerfilter/source/doctok/resources.xsl
+++ b/main/writerfilter/source/doctok/resources.xsl
@@ -576,7 +576,7 @@ class </xsl:text>
               <xsl:value-of select="$mask"/>
             </xsl:if>
             <xsl:text>)</xsl:text>
-            <xsl:if test="$shift>0">
+            <xsl:if test="string-length($shift)>0 and $shift>0">
               <xsl:text>&gt;&gt; </xsl:text>
               <xsl:value-of select="$shift"/>
             </xsl:if>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]