I want someone to have a look at SF patch 888839 and check it in
if it looks fine. It is a one-line patch.
This solves a problem mentioned in following threads:
The first thread suggests linking with libstdc++ or hacking
distutils.sysconfig to link with g++, which doesn't feel right.
The second thread says linking with libstdc++ hack doesn't work
any more with 2.3, because 2.3 'fixed' the problem: it
autodetects C++ file and invokes nonexistent 'cc'.
I apologize if this is somewhere in the archives, I did a quick scan of
the topics over the last while and couldn't find anything. Anyway, as
was pointed on somewhere after Googling, that intermixing stuff built
with Visual Studio 7 with stuff from VS6 may result in bad things
happening, so that's why distutils included with python 2.3 produces a
"Python built with VS6, extensions must be built with it too" type
message. However, I downloaded a source distribution, went into the
PCBUILD dir and rebuilt the lot. I'm using the source tree (with the
built binaries moved to appropriate places) as my python installation,
but I still get the same message. Does anyone have any idea how I can
get around this? It's probably really easy and obvious but I'm not
accustomed to building Python from source.
Your submission to the list has been forwarded to the list
owner <owner-mutt-announce(a)mutt.org> for approval because you do not seem to be on
If you want to join the list, send email to <Majordomo(a)mutt.org>, with
"subscribe mutt-announce" in the message text (not the subject).
From: Mark Hammond
>> Just to understand this: will this mean that you have to have VC7
>> in order to build extensions for Python 2.4 and onwards ?
> Officially, I think it will. Unofficially, it will remain like it does
> today - it *may* work (depending on if you try and use Python API functions
> that use FILE objects). IIRC, there used to be a problem of you implemented
> objects, as the malloc/free pairs happened in different CRTLs, but I think
> that in recent versions the macro-magic means they do match)
I believe that mingw will build extensions which work with Python 2.3 and 2.4,
because mingw supports both MSVC runtimes. You still have to build the
extension using distutils from the appropriate Python version (ie, you need
2 Python versions installed).
> A Python API function "PyFile_OpenFile()" would also solve this issue, but
> obviously that wouldn't exist in 2.3 or earlier, so doesn't help this
> specific case.
According to Martin von Loewis, this is a lost cause - mixing runtimes is
never OK, even if you don't use "dangerous" functions (like ones which use
FILE*). However, in practical terms, I've never generated a problem (although
I haven't tried very hard).
>> I think it is worthwhile (and have always argued that way) to have one
>> distutils version which can create Python distributables for various
>> Python versions, including as many older versions as possible.
> I believe that is the intent. There is one other small issue I had trying
> to do this for win32all, but I will address that later.
>> Does the move to VC7 mean that we'll break this strategy with
>> Python 2.4 distutils ?
> Yes, unless we do as outlined in my mail.
I may be misunderstanding what is being discussed here, but I believe that with
the move to VC7, you will need the following to build extensions compatible with
both Python 2.3 and 2.4:
1. Installed copies of both Python 2.3 and 2.4.
2. EITHER MSVC 6 and 7 (both versions) OR mingw
But I am probably missing something, as once you have the 2 versions of Python
installed, I don't see the value in using a single shared distutils, rather than
the one that comes with each Python.
Okay I have tried to modify the tail a little... I hope that it is now a
little less tick-like...
My other idea was a Python-in-a-box...but I prefered this...
"Requirements - what are they I just hack something together that does what
I think they want" ;)