[lxml-dev] Building lxml 2.1.2 on windows
Hi all, I'm trying to build lxml 2.1.2 for python 2.5 on windows, but the linking fails with the following error: lxml.etree.obj : error LNK2019: unresolved external symbol _xsltProcessOneNode referenced in function ___pyx_pf_4lxml_5etree_13XSLTExtension_apply_templates I would like to link the libxml and the other libraries to lxml dynamically, not statically. Is it possible? It seems to me that xsltProcessOneNode is not defined in the windows version of libxslt (btw it's not defined in any .h files), however it's defined in unix .so files. I've installed all the dependencies, libxml version 2.6.31, libxslt 1.1.22, zlib 1.2, iconv 1.9, and using VC7.1 for building. Could you please advice on this? Any help/ideas would be appreciated. Thanks, Zsolt -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Not sure I can provide any help for you, but I wanted to ask a few questions out of curiosity: - Why do you want a dynamically linked version? - Why can't you use the already existing binaries? Oh, one reason why the build might be failing for you is that you are trying to use libxml 2.6.x, and we depend on 2.7.x? On Wed, Oct 29, 2008 at 7:46 AM, Cserna, Zsolt (IT) <Zsolt.Cserna@morganstanley.com> wrote:
Hi all,
I'm trying to build lxml 2.1.2 for python 2.5 on windows, but the linking fails with the following error:
lxml.etree.obj : error LNK2019: unresolved external symbol _xsltProcessOneNode referenced in function ___pyx_pf_4lxml_5etree_13XSLTExtension_apply_templates
I would like to link the libxml and the other libraries to lxml dynamically, not statically. Is it possible? It seems to me that xsltProcessOneNode is not defined in the windows version of libxslt (btw it's not defined in any .h files), however it's defined in unix .so files.
I've installed all the dependencies, libxml version 2.6.31, libxslt 1.1.22, zlib 1.2, iconv 1.9, and using VC7.1 for building.
Could you please advice on this?
Any help/ideas would be appreciated.
Thanks,
Zsolt --------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. _______________________________________________ lxml-dev mailing list lxml-dev@codespeak.net http://codespeak.net/mailman/listinfo/lxml-dev
-- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc
Hi, Sidnei da Silva wrote:
Oh, one reason why the build might be failing for you is that you are trying to use libxml 2.6.x, and we depend on 2.7.x?
Absolutely not. lxml 2.0 and 2.1 should still work with libxml2 2.6.21 (I think even 2.6.20, haven't tested for a while :). Depending on 2.7.x would mean that we drop support for virtually all existing systems out there. That's not going to happen. Stefan
Hi,
Not sure I can provide any help for you, but I wanted to ask a few questions out of curiosity:
- Why do you want a dynamically linked version? - Why can't you use the already existing binaries?
We already have the dependent libraries compiled and installed in our infrastructure, and every application links dynamically (eg the perl libxml module). It's the most optimal way if for example a bug is fixed in libxml, we simply replace the libxml binary and no re-compilation is needed in the other dependent applications.
Oh, one reason why the build might be failing for you is that you are trying to use libxml 2.6.x, and we depend on 2.7.x? I don't think so..
Yesterday I've discovered that the symbol in question (xsltProcessOneNode) is not exported on windows in libxslt, and also missing from .h files. Is it a public method? In unix .so and in windows static .lib file all the functions are exported so in these situations the dynamic linking is possible. So I think the solution for this error would be either: - You could remove the dependency of xsltProcessOneNode from lxml. :) - Export the method in libxslt (which has a different forum/mailing list, I think). Since libxslt is open source, we can do the modification ourselves and have the "patched" version but I think it could be useful for the other people who want to link dynamically to libxslt. Zsolt
Hi all,
I'm trying to build lxml 2.1.2 for python 2.5 on windows, but the linking fails with the following error:
lxml.etree.obj : error LNK2019: unresolved external symbol _xsltProcessOneNode referenced in function ___pyx_pf_4lxml_5etree_13XSLTExtension_apply_templates
I would like to link the libxml and the other libraries to lxml dynamically, not statically. Is it possible? It seems to me that xsltProcessOneNode is not defined in
On Wed, Oct 29, 2008 at 7:46 AM, Cserna, Zsolt (IT) <Zsolt.Cserna@morganstanley.com> wrote: the windows version of libxslt (btw it's not defined in any .h files), however it's defined in unix .so files.
I've installed all the dependencies, libxml version 2.6.31,
libxslt 1.1.22, zlib 1.2, iconv 1.9, and using VC7.1 for building.
Could you please advice on this?
Any help/ideas would be appreciated.
Thanks,
Zsolt --------------------------------------------------------
NOTICE: If received in error, please destroy and notify
sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
_______________________________________________ lxml-dev mailing list lxml-dev@codespeak.net http://codespeak.net/mailman/listinfo/lxml-dev
-- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc
-------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Cserna, Zsolt \(IT\) wrote:
Yesterday I've discovered that the symbol in question (xsltProcessOneNode) is not exported on windows in libxslt, and also missing from .h files. Is it a public method? In unix .so and in windows static .lib file all the functions are exported so in these situations the dynamic linking is possible.
I just checked the libxslt sources and it is missing from the header files, everywhere back to at least 1.1.11. So it is not a public function. The call was introduced into lxml to implement XSLT extension elements. I don't remember how I found the function at the time, apparently not through the official API docs. Note that it's not static in the libxslt sources, although it is only used in transform.c. So I assume that it was at least considered for being made public at the time it was written. So there is still space for a post to the libxslt list.
So I think the solution for this error would be either: - You could remove the dependency of xsltProcessOneNode from lxml. :)
That would be the right thing to do, as this problem means that we can't currently support older libxslt versions, even if the function becomes public in a new release. I definitely take patches, but failing contributions, I will have to find a different way to implement the apply_templates() method in the XSLTExtension class, or drop the feature all-together for now. Dropping apply_templates() will however reduce the value of custom XSLT elements considerably.
Since libxslt is open source, we can do the modification ourselves and have the "patched" version but I think it could be useful for the other people who want to link dynamically to libxslt.
Yes, this is a temporary solution, but only for users like you who build their own customisable libxslt. Stefan
participants (3)
-
Cserna, Zsolt (IT) -
Sidnei da Silva -
Stefan Behnel