Re: [xslt] libxslt 1.0.33 + libxml2 2.6.0 'IS_BLANK' problem

["William M. Brack" <wbrack mmm com hk>]

Igor Zlatkovic said:
>> Hiya,
>>
>> I'm building libxslt 1.0.33 against libxml2 2.6.0. I get a fatal
>> error
> from
>> the compiler whilst compiling libxslt/xslt.c :
>>
>> "c.xslt", line 66: Error: differing redefinition of #define macro
>> IS_BLANK
>>
>> xslt.c has the macro declared :
>>
>> #define IS_BLANK(c) (((c) == 0x20) || ((c) == 0x09) || ((c) ==
>> 0xA) || \
>>                      ((c) == 0x0D))
>>
>> However, xslt.c also includes libxml/parserInternals.h which has
>> the
>> definition :
>>
>> #define IS_BLANK(c)  xmlIsBlankQ(c)
>>
>>
>> I'm not sure what the behaviour of GCC is on such redefinitions,
>> but the
>> Norcroft compiler (which is used for my RISC OS builds) treats a
>> differing
>> redefinition as a fatal error. Such use must be #undef'd before
>> the new
>> definition can be used.
>>
>> Is this actually a mistake that I've made, or is this redefinition
>> not a
>> problem for GCC ?
>
> Probably not. I know that MS compiler issues a warning on that one
> and
> continues.
>
> However, perhaps this should be handled. Either xmlsec or xsldbg has
> the
> same somewhere in the code, I cannot remember which it was.
>
> I suggest that IS_BLANK from libxml be used everywhere. If there are
> no
> objections, I'll commit what I can.
>
> Ciao,
> Igor

First, with regard to GCC, this "redefinition" only results in a
warning.  Second, there is a problem with using the definition from
parserInternals.h.  This problem comes from changes in version 2.6.0
of libxml2, where all of the IS_XXXX macros have been changed (for
better performance) to use the new range routines.  Eventually
similar enhancements will be made to libxslt, but there is some risk
to ABI compatibility (since there must be a hard dependency on
linking to libxml2-2.6.0 or greater).  I believe that currently the
dependency is only for 2.5.10.

So, the "proper" fix is to do as Igor suggests, and just remove the
definition from xslt.c, but in order to maintain ABI compatibility,
for now we should just #undef it.  I'll do that now, and commit it
to CVS.

Sorry for the problem - if I knew it would break any compilation I
would have fixed it previously.

Regards,

Bill