This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new libxml2 / libxslt packages?


[Sorry for the delay in following up on my own post...]

I wrote:

me> I was wondering whether there were plans to release new versions
me> of libxml2 and libxslt.  The versions that are part of Cygnus now
me> are all rather old (by almost a year in the case of libxslt).  ...

>>>>> "NW" == Nicholas Wourms wrote:

NW> I'm sure Robert's aware of this, but he's got enough to do without
NW> having to update these.  They work quite fine at their current
NW> version, so I'll let him decide when it is appopriate to update.

Well, "work" is a relative term... ;-)  

There have been some fairly major bug fixes in libxml2 between 2.4.23
and 2.5.2 (just released on 5th of Feb), and particularly for libxslt
between 1.0.13 and 1.0.25, that fixed bugs in XSLT engine that
resulted in transformations were incorrect with respect to the XSLT
specification (such as the semantics of the "node()" function).

See: http://xmlsoft.org/news.html and http://xmlsoft.org/XSLT/news.html

These bugs can affect users of the Norman Walsh's DocBook XSL
stylesheets, and it means that the current version of xsltproc may not
work and/or can produce erroneous output if used in conjunction with
the recent versions of the DocBook XSL stylesheets.

So I'd call the current version(s) "broken" if they have known lack of
conformance with XML/XSLT W3C specs [using the latest DocBook
stylesheets to check whether libxslt is "working" is a good test,
because these stylesheets really exercise a good portion of the XSLT
spec].

>>>>> "RC" == Robert Collins writes:

RC> I hope to do a update-and-test run shortly. Updating these
RC> packages tends to be a little painful, or I'd do it more often :}.

I feel your pain from trying to compile them from source myself.

Incidentally why is to so difficult to compile the original sources
out-of-the-box?  If there are fixes you need to make (e.g. source or
build files like Makefile.am, configure.in etc)., have you been
feeding them back to Daniel Veillard so that he can put them in the
mainline source?  The easier it is to build without mods on vanilla
Cygwin, the easier it would be to test new releases of the pristine
sources on Cygwin and reduce your load in packaging...

If you want to send me a modified version of the most currently
released source that should compile out-of-the-box with a simple
configure/make/make install, I'd be happy to test them.

NW> Another issue is that the python binding requires some reworking
NW> in 2.5.1, because it currently contains some relocation issues
NW> which prevent it from properly linking.  This could also be fixed
NW> with a newer ld, which supports pseudo relocations.

RC> Ah. Well, I don't use python - I'm happy to roll patches into the
RC> builds, but have no innate interest in troubleshooting the
RC> issues. I'll get a beta together in the near future, and let a
RC> python user fiddle :].

[...]

I'd be happy to try it, I really need to use the Python bindings to
libxslt.  At the very least it's inconsistent to have Pythons bindings
for the libxml2 package but not for libxslt... ;-)

Does the building libxslt with  Python bindings simply not work, or
are these bugs that show up after it's built and installed.

Cheers, Alex



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]