Re: [lxml-dev] windows compiler error: string too big
Hi Steve, Steve Howe wrote:
I was trying to build the Windows eggs, when got the following:
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iz:/xml/include - IZ:\python24\include -IZ:\python24\PC /Tcsrc/lxml/etree.c /Fobuild\temp.win32-2.4\Release\src/lxml/etree.obj -w cl : Command line warning D4025 : overriding '/W3' with '/w' etree.c src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated src\lxml\etree.c(964) : error C2026: string too big, trailing characters truncated error: command '"C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe"' failed with exit status 2
And indeed, that line is quite large (~32kb)... what should I do ?
Oh well, how is that for a bug. :)
That compiler is the same which compiled Python, so its the "official" one.
Then it's the right one to use.
Could that string be broken apart ?
No problem. Here's a patch that does that. Compiles nicely on my machine. Likely adds nothing but a microsecond to the setup time, but is a little harder to maintain as we have to remember to apply something alike when we update the error code constants. Just apply the patch to the official version and compile that. I'll see if I can find a better patch for the trunk. As we know, most people won't compile under windows themselves, so that's not really something we need corrected in the source distribution. Sorry for the hassle. Stefan Index: src/lxml/xmlerror.pxi =================================================================== --- src/lxml/xmlerror.pxi (Revision 28057) +++ src/lxml/xmlerror.pxi (Arbeitskopie) @@ -561,6 +561,8 @@ XML_NS_ERR_QNAME = 202 : 202 XML_NS_ERR_ATTRIBUTE_REDEFINED = 203 : 203 XML_NS_ERR_EMPTY = 204 : 204 +""" + \ +""" XML_DTD_ATTRIBUTE_DEFAULT = 500 XML_DTD_ATTRIBUTE_REDEFINED = 501 : 501 XML_DTD_ATTRIBUTE_VALUE = 502 : 502 @@ -727,6 +729,8 @@ XML_RNGP_VALUE_NO_CONTENT = 1120 : 1120 XML_RNGP_XMLNS_NAME = 1121 : 1121 XML_RNGP_XML_NS = 1122 : 1122 +""" + \ +""" XML_XPATH_EXPRESSION_OK = 1200 XML_XPATH_NUMBER_ERROR = 1201 : 1201 XML_XPATH_UNFINISHED_LITERAL_ERROR = 1202 : 1202 @@ -1017,6 +1021,8 @@ XML_SCHEMAV_CVC_TYPE_2 = 1876 : 1876 XML_SCHEMAV_CVC_IDC = 1877 : 1877 XML_SCHEMAV_CVC_WILDCARD = 1878 : 1878 +""" + \ +""" XML_XPTR_UNKNOWN_SCHEME = 1900 XML_XPTR_CHILDSEQ_START = 1901 : 1901 XML_XPTR_EVAL_FAILED = 1902 : 1902
Hello Stefan, Friday, June 2, 2006, 2:37:20 AM, you wrote:
No problem. Here's a patch that does that. Compiles nicely on my machine. Likely adds nothing but a microsecond to the setup time, but is a little harder to maintain as we have to remember to apply something alike when we update the error code constants. [...]
Thanks, it worked, but now we the same thing on line 972: etree.c src\lxml\etree.c(972) : error C2026: string too big, trailing characters truncated Every line above 32000 chars will not be compiled. I could be fixing those myself, but I think it's better to have it right in the trunk... -- Best regards, Steve mailto:howe@carcass.dhs.org
Hi Steve, Steve Howe wrote:
Friday, June 2, 2006, 2:37:20 AM, you wrote:
No problem. Here's a patch that does that. Compiles nicely on my machine. Likely adds nothing but a microsecond to the setup time, but is a little harder to maintain as we have to remember to apply something alike when we update the error code constants. [...]
Thanks, it worked, but now we the same thing on line 972:
etree.c src\lxml\etree.c(972) : error C2026: string too big, trailing characters truncated
Every line above 32000 chars will not be compiled. I could be fixing those myself, but I think it's better to have it right in the trunk...
That's the same place as before. Are you sure the maximum is 32k? Because the patch I sent you should have cut the longest line down to some 13k... Maybe setup.py didn't rebuild etree.c? That's not done automatically because we only have it depend on etree.pyx (in which there were no changes). I sent you a generated etree.c where the longest line is below 8k. But I'll look into the issue to fix it on the trunk... Stefan
Ok, one for the archives. MSVC only supports strings of up to 2048 bytes, so we had to find a way how to split these up. Steve wrote a little script that does that in etree.c. It makes lxml compile, but doesn't work well with distutils, so that's not really an option. I wrote a new script "update-error-constants.py" that fixes the problem at the root. Since we have to update the constants from time to time anyway to support new libxml2 versions, this script parses the HTML documentation page of libxml2 (it obviously uses lxml for that :) and generates the declarations in xmlerror.pxd and xmlerror.pxi. The strings it puts into the .pxi are split at about 2000 bytes, so that fixes the MSVC problem. To update the constants for a new version of libxml2, run the script as follows: cd /path/to/lxml python update-error-constants.py /path/to/libxml2-doc-dir it will then pick up the file "html/libxml2-xmlerror.html" from that directory and parse it. A "svn ci" will do the rest, but please remember running "make clean test" first! Stefan
participants (2)
-
Stefan Behnel -
Steve Howe