Distutils-SIG April 2005

distutils-sig@python.org

27 participants
26 discussions

Start a nNew thread

(no subject)
by giles＠cvs.ghostscript.com 04 Apr '05

04 Apr '05

The message contains Unicode characters and has been sent as a binary attachment.

1 0

STATUS
by brian_dunfordshore＠bridge.com 04 Apr '05

04 Apr '05

The message contains Unicode characters and has been sent as a binary attachment.

1 0

gnotenwgtdvhq
by ctichler＠cloud9.net 04 Apr '05

04 Apr '05

The message contains Unicode characters and has been sent as a binary attachment.

1 0

HELLO
by niepraschk＠chbrb.berlin.ptb.de 04 Apr '05

04 Apr '05

The message contains Unicode characters and has been sent as a binary attachment.

1 0

Mingw Python 2.4
by AGiss 03 Apr '05

03 Apr '05

Hello, I tried to compile some extensions under Windows/Python 2.4 using distutils and mingw as compiler (not MS-VC++). ----- (You can just jump to conclusion at the bottom if you like, but be aware that I don't really master the subject, so I may have missed something. If you thing my conclusions doesn't make sense, please read what happens to me.) ----- (Official Python2.4, the one that use msvcr71.dll) I got some strange results like "the softwares I wrote using this extension crashed randomly". I first thought that extension (that I didn't wrote) was crappy. When the second extension crashed too, I tried to understand a bit more. The crash is more or less random, (but when it doesn't crash, everything works as expected even the code in the extension) and it crash with an OS error 0xc0000008 (it look like it's an internal windows error which mean there is something really nasty with the memory. So the .pyd was linked to msvcrt.dll and to msvcr71.dll. As it looks fishy, I tried to reinstall python 2.3 for windows that doesn't use msvcr71.dll but msvcrt.dll). I wasn't able to reproduce the crash. Then I realize the extension provided a way to build the same .pyd (but I wasn't able to generate an installer for the extension, that's why I didn't use it). So I look at the .pyd generated for python 2.4 with the makefile, and... it was only linked to msvcrt.dll. So I trie to use it instead and... it works !!! I tried to recompile everything from scratch using distutils because it may just be because a "bad neutrino who hit my motherboard at the worst moment", but the bug was still here. So I tried to figure out what was the difference between the command lines used by the makefile and distutils. And... the obvious difference was that distutils used a -lmsvcr71. Gooood I looked at distutils code source, and quickly found the line that makes mingw use msvcr71. IV just changed it. I rebuild all, and... It just worked well. (and of course, the .pyd was just linked to msvcrt and not msvcr71 anymore) -------------- Sooooooooooooooooo here are my conclusions : Something isn't right when compiling with mingw using msvcr71. (command line option ? problem with mingw ? problem with msvcr71 ? mingw just need some more configuration to works with msvcr71 ? I don't really know) It *look* like compilling extension using msvcrt instad of msvcr71, even if python use msvcr71 is safer that letting mingw using msvcr71. So I propose to remove the lines from 330 to 332 on the file cygwinccompiler.py (revision 1.29, the actual one, and the one used with python 2.4) The code is specific for Windows/Mingw/(python compiled with msvc 7.1) so there shouldn't be any side effect. Perahps it's wise to do the same for the line that add "msvcr70" (but I don't know). Perhaps it's wise to do the same on lines 130-135 (The same code, but for cygwin's internal gcc, and not mingw's gcc), but I don't know if cygwin suffer for the same problems.

2 2

Re: [Distutils] small improvement of the script functionality under win32
by Vivian De Smedt 03 Apr '05

03 Apr '05

Here is a small summary of the remark made arround the she-bang modification of the windows platform. 1. Trent let us know that the she-bang modification works only for the win nt sons and that in general it is better to use the .bat extension instead of the .cmd one 2. I realize that we shouldn't change the extension of a script if it exist since the extention could be usefull to determine which version of python to run - pythonw for the .pyw extention - python for the .py extention According to these remarks and in the purpose to be as conservative as possible I make this another proposition: The change in the she bang will happend only if - the win32 platform is detected (os.name == "nt") - the platform is win NT son (os.environ["OS"] == "Windows_NT") - the original script had no extension (os.path.splitext(outfile)[1] == "") Furthermore I add the %* in the new nt she-bang to let the underlying script know about command line argument. such that the unix she-bang: #!python foo bar will become: @C:\Python24\Python.exe -x "%%~f0" foo bar %* & exit /b I think that in these conditions the change could only improve the existing situation at least it improve for some them (Zope, Chetaah, PyCrust, IPython) Tell me what you think about the proposed change. Vivian.

4 7

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG April 2005