[XML-SIG] pyxml 0.7 and cygwin

[Mark McEahern]

> From: Martin v. Loewis [mailto:martin@v.loewis.de]
> Hmm. This refers to
>
>     {"ProcessingInstructionHandler",
>      (xmlhandlersetter)XML_SetProcessingInstructionHandler, /*line 1800*/
>      (xmlhandler)my_ProcessingInstructionHandler},
>
> Right? I fail to see what it complains about;
> XML_SetProcessingInstructionHandler *is* constant. What gcc version is
> that?
>
> Can you try replacing that with
>
>     {"ProcessingInstructionHandler",
>      (xmlhandlersetter)&XML_SetProcessingInstructionHandler,
>      (xmlhandler)my_ProcessingInstructionHandler},

I tried this as you suggested and it does not change the result:

extensions/pyexpat.c:1800: initializer element is not constant
extensions/pyexpat.c:1800: (near initialization for
`handler_info[2].setter')

> Unless I'm missing something obvious, this looks like a bug in gcc to
> me. Since my gcc on Linux accepts this just fine, I'd say it is a
> cygwin bug.

This is a little over my head; however, could it have something to do with
this?

http://www.cygwin.com/ml/cygwin/1999-11/msg00397.html

(I found that searching for __declspec with Google.)

>From expat.h, line 11:

#ifndef XMLPARSEAPI
#  if defined(__declspec) && !defined(__BEOS__)
#    define XMLPARSEAPI(type) __declspec(dllimport) type __cdecl
#  else
#    define XMLPARSEAPI(type) type
#  endif
#endif  /* not defined XMLPARSEAPI */

I replaced that with this:

#ifndef XMLPARSEAPI
#    define XMLPARSEAPI(type) type
#endif  /* not defined XMLPARSEAPI */

and it compiled just fine.  Please understand, *I have no sense of the
implication of this*.  Consider me as slightly better than a random monkey
when it comes to C++.  There is in all likelihood a better fix.

Hmm, now what should I do?

For what it's worth, here are the results from regrtest.py:

$ regrtest.py
test_c14n
test test_c14n failed -- Writing: '\n', expected: '\r'
test_dom
test test_dom failed -- Writing: '\n', expected: '\r'
test_domu
test test_domu failed -- Writing: '\n', expected: '\r'
test_encodings
test_howto
test test_howto failed -- Writing: '\n', expected: '\r'
test_htmlb
test test_htmlb failed -- Writing: '\n', expected: '\r'
test_javadom
test test_javadom failed -- Writing: '\n', expected: '\r'
test_marshal
test test_marshal failed -- Writing: '\n', expected: '\r'
test_minidom
test test_minidom failed -- Writing: '\n', expected: '\r'
test_pyexpat
test test_pyexpat failed -- Writing: '\n', expected: '\r'
test_pyxmldom
Warning: can't open ./output/test_pyxmldom
test_sax
test test_sax failed -- Writing: '\n', expected: '\r'
test_sax2
test test_sax2 failed -- Writing: '\n', expected: '\r'
test_sax2_xmlproc
test test_sax2_xmlproc failed -- Writing: '\n', expected: '\r'
test_sax_xmlproc
test test_sax_xmlproc failed -- Writing: '\n', expected: '\r'
test_saxdrivers
test test_saxdrivers failed -- Writing: '\n', expected: '\r'
test_utils
test test_utils failed -- Writing: '\n', expected: '\r'
2 tests OK.
15 tests failed: test_c14n test_dom test_domu test_howto test_htmlb
test_javadom
 test_marshal test_minidom test_pyexpat test_sax test_sax2 test_sax2_xmlproc
tes
t_sax_xmlproc test_saxdrivers test_utils

> However, I'm also surprised that it does not pass
> -Iextensions/expat/lib to the compiler. Where does it get expat.h
> from, then? Can you print ext_modules in setup.py right before setup
> is invoked? Can you also try to trace how the value of include_dirs
> gets lost?

include_dirs isn't getting lost.  Let me recopy the gcc call, but format the
line so that it's more readable:

building '_xmlplus.parsers.pyexpat' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
  -DUSE_DL_IMPORT -DHAVE_EXPAT_H -DVERSION="1.95.2"
  -DXML_NS=1 -DXML_DTD=1 -DXML_BYTE_ORDER=12
  -DXML_CONTEXT_BYTES=1024 -Iextensions/expat/lib
  -I/usr/include/python2.2 -c extensions/pyexpat.c
  -o build/temp.cygwin-1.3.6-i686-2.2/pyexpat.o

Thanks,

// mark