This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lkcl
Recipients cfriedt, hanwen, janneke-sf, lkcl, loewis, nzjrs, rmt38, rwmjones, scott.tsai
Date 2008-10-06.14:52:26
SpamBayes Score 8.585326e-09
Marked as misclassified No
Message-id <1223304748.48.0.964897670514.issue1597850@psf.upfronthosting.co.za>
In-reply-to
Content
ok.

what's not explained, and isn't clear, is exactly whether you're
supposed to - or even _capable_ of - cross-compiling the _entire_
python sourcecode base with mingw32, or whether you're supposed to
get _just_ the python.exe interpreter, and, maybe if you're lucky,
libpython.a (or libpython.dll - whatever).

i got quite a long way, as you can see, in cross-compiling
posixmodule.c _by mistake_ - before realising that the whole
python sourcecode base is completely inadequately set up for
cross-compiling, but is specialised "hard-coded" to compile
python under msvc _only_.

so, when doing the cross-compile, it was actually being detected
as a _unix_ compile, not a _win32_ compile.

#define WIN32 wasn't even being listened to.

the end result was that entire areas of posixmodule.c were
being compiled when they shouldn't have been.

later, i tried to correctly #define WIN32 (or whatever was
required), only to find that the mingw32 libraries don't
support many of the necessary functions.  for example, it's
assumed that crypto libraries exist, and many other things.

all in all, it didn't go too well :)
History
Date User Action Args
2008-10-06 14:52:28lkclsetrecipients: + lkcl, loewis, hanwen, janneke-sf, rmt38, scott.tsai, nzjrs, cfriedt, rwmjones
2008-10-06 14:52:28lkclsetmessageid: <1223304748.48.0.964897670514.issue1597850@psf.upfronthosting.co.za>
2008-10-06 14:52:27lkcllinkissue1597850 messages
2008-10-06 14:52:26lkclcreate