Building extensions with mingw32 -- bdist_wininst fails.

  • Thread starter Chris Gonnerman
  • Start date
C

Chris Gonnerman

I'll be quick. Here's a transcript:

C:\usr\WConio-1.5>python setup.py build --compiler=mingw32
running build
running build_py
running build_ext
building '_WConio' extension
writing build\temp.win32-2.3\Release\_WConio.def
C:\MINGW32\BIN\dllwrap.exe -mno-cygwin -mdll -static --output-lib
build\temp.win
32-2.3\Release\lib_WConio.a --def
build\temp.win32-2.3\Release\_WConio.def -s bu
ild\temp.win32-2.3\Release\wconiomodule.o -LC:\PYTHON\libs -LC:\PYTHON\PCBui
ld -
lpython23 -o build\lib.win32-2.3\_WConio.pyd

C:\usr\WConio-1.5>python setup.py bdist_wininst
running bdist_wininst
running build
running build_py
running build_ext
error: Python was built with version 6 of Visual Studio, and extensions need
to
be built with the same version of the compiler, but it isn't installed.

I checked the archives regarding that error message and found a conversation
wherein Jeremy Hylton claimed he might have added the code to detect this,
and Paul Moore asked to have it removed/disabled at least for mingw32 (which
makes binaries 100% compatible with MSVC6). In the case given then, the
extension wouldn't build at all; now it builds but I can't make a Windows
installer from it.

mingw32 should be treated as 100% equivalent to MSVC6 in all cases...
please. I've got people clamoring for two of my extensions (and I didn't
even think they were popular) but I can't build installers.

Is there any way I can get this to work? If I have to I'll hack that check
out of Distutils with an axe, but still this should be fixed.

Chris Gonnerman -- (e-mail address removed)
http://newcenturycomputers.net
 
T

Thomas Heller

[posted and mailed]
Chris Gonnerman said:
I'll be quick. Here's a transcript:

C:\usr\WConio-1.5>python setup.py build --compiler=mingw32
running build
running build_py
running build_ext
building '_WConio' extension
writing build\temp.win32-2.3\Release\_WConio.def
C:\MINGW32\BIN\dllwrap.exe -mno-cygwin -mdll -static --output-lib
build\temp.win
32-2.3\Release\lib_WConio.a --def
build\temp.win32-2.3\Release\_WConio.def -s bu
ild\temp.win32-2.3\Release\wconiomodule.o -LC:\PYTHON\libs -LC:\PYTHON\PCBui
ld -
lpython23 -o build\lib.win32-2.3\_WConio.pyd

C:\usr\WConio-1.5>python setup.py bdist_wininst
running bdist_wininst
running build
running build_py
running build_ext
error: Python was built with version 6 of Visual Studio, and extensions need
to
be built with the same version of the compiler, but it isn't installed.

I checked the archives regarding that error message and found a conversation
wherein Jeremy Hylton claimed he might have added the code to detect this,
and Paul Moore asked to have it removed/disabled at least for mingw32 (which
makes binaries 100% compatible with MSVC6). In the case given then, the
extension wouldn't build at all; now it builds but I can't make a Windows
installer from it.

Can you point me to this discussion, please? Then I'll try to look after
this.

Thomas
 
C

Chris Gonnerman

----- Original Message -----
I have no trouble doing what you describe (with Python 2.1.3, 2.2.3,
or 2.3).

The core Pythons I'm using were compiled with MSVC 6 SP5 on Windows
2000 SP4, but I can build extension modules and installers just fine
with MinGW (3.0-rc4). The only preparatory step was to generate
libpythonXX.a, as described in the Section 6.2.2 of the standard
library docs.

Are you sure your compiler setup is correct? Was the core Python 2.3
you're using actually built with MSVC 6, as the error message claims?

Well, now I'm not sure. Is the installer binary from
python.org built with MSVC 6 or something else?

If it is something else, do I have to upgrade my MinGW32 gcc? It's
currently 2.95.2 I think.

Chris Gonnerman -- (e-mail address removed)
http://newcenturycomputers.net
 
P

Pierre Schnizer

Chris Gonnerman said:
----- Original Message -----

Please excuse, if it is a bit out topic.

When I tried to build an extension module for Python2.2 with MingW3.0 I had
problems with the conversion of files. So

myfile = PyFile_AsFile(object);

would crash python2.2 when a standard Python2.2 was invoking an extension
module compiled with MinGW.

Do you use such conversions in your Module?

Thanks for your help
Best Regards
Pierre
 
T

Thomas Heller

[posted and mailed]

Chris Gonnerman said:
Thanks! First, here's where I found the messages I refer
to above:

http://mail.python.org/pipermail/distutils-sig/2003-July/003339.html

OK, here's the problem. The distutils bdist_wininst
script calls build (illustrated below) but does not
accept --compiler=mingw32. This is obviously wrong,
but I'm unsure how to fix it (I'm still trying to wrap
my fuzzy and tired mind around the entire distutils
thing).


There's an easy workaround.
python setup.py bdist_wininst --compiler=mingw32
does *not* work.
But this one does:

python setup.py build --compiler=mingw32 bdist_wininst

Maybe this should be documented somewhere?

I've tried it with one of my simple extension modules at least,
and after hacking msvccompiler so that this one isn't found any longer.

Thomas
 
C

Chris Gonnerman

----- Original Message -----
Please excuse, if it is a bit out topic.

When I tried to build an extension module for Python2.2 with MingW3.0 I had
problems with the conversion of files. So

myfile = PyFile_AsFile(object);

would crash python2.2 when a standard Python2.2 was invoking an extension
module compiled with MinGW.

Do you use such conversions in your Module?

No, I don't. That's interesting, though... thanks for
the information.

Chris Gonnerman -- (e-mail address removed)
http://newcenturycomputers.net
 
T

Thomas Heller

Chris Gonnerman said:
Well, whaddaya know, it works! Thanks!

I still think the bdist*.py scripts should accept
--compiler=mingw32 (or whatever) as a matter of
correctness, if nothing else; but I can live with
this. Perhaps if I get time I'll work up a patch.

I'm not so convinced that this is needed. I always view the disutils
commands as a stack or chain, and the command line above can be used to
inject flags in vertain places in the chain. the build commands, for
example, accept quite some parameters which are not valid for the
install or (s|b)dist commands (--debug is another example).
So, to install debug versions, one would use
python setup.py build --debug install
which also looks natural to me.

The --compiler problem may be unique because obviously the build command
constructs a compiler instance even if it has nothing to do, and the
build command is run from bdist_wininst to make sure everything is ok.

Oh, and yet another way, which you may want to try, is to write an
(maybe even site-global) distutils configuration file containing
[build]
compiler = mingw32
If this works, you no longer have to remember to give the compiler
option on the command line.

Thomas
 
J

John Machin

Pierre Schnizer said:
Please excuse, if it is a bit out topic.

You're excused.
When I tried to build an extension module for Python2.2 with MingW3.0 I had
problems with the conversion of files. So

myfile = PyFile_AsFile(object);

would crash python2.2 when a standard Python2.2 was invoking an extension
module compiled with MinGW.

If Python is compiled with compiler X, and an extension is compiled
with compiler Y, there is a very high chance that the runtime support
for files is quite different. What X's FILE* points to will be
different to what Y's FILE* points to.

Although MinGW uses the MSVC runtime msvcrt.dll, it's not the sort of
thing you should bet your last dollar on. For portability, always
assume that X != Y.

So, either (1) get a filename from the Python caller, and fopen it
yourself, and use stdio functions on the FILE* or (2) get a
PyFileObject* from the Python caller, and use the high-level API
functions on that e.g. PyFile_GetLine, PyFile_WriteString [not useful
if you have embedded '\0' in your string], PyFile_WriteObject.

IMHO, PyFile_AsFile() and PyFile_FromFile() should have severe
warnings in the documentation.

Hope this helps,
John
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top