(Python newbie) Using XP-SP2/MSVC6: No Python24_d.lib, winzip barfs on Python-2.4.1.tar, cannot down

[Bill Davy]

I downlaoded and installed
http://www.python.org/ftp/python/2.4.1/python-2.4.1.msi

I'm trying to build an extension using SWIG 1.3.24 and the linker needs
python24_d.lib (I do not have the DLL either). I've not found it in any of
the
downloads.

So I tried to download the source to build it myself. Of
http://www.python.org/ftp/python/2.4.1/Python-2.4.1.tar.bz2 and
http://www.python.org/ftp/python/2.4.1/Python-2.4.1.tgz, WinZip (9.0 SR1)
just says "Error reading header after processing 0 entries".

Additionally, I've had no joy downloading the unzipper
(ftp://sources.redhat.com/pub/bzip2/v102/bzip2-102-x86-win32.exe) from the
site cited for the unzipper (http://sources.redhat.com/bzip2/). It flashed
up a
black console window momentarily.

Oh, this is sooooo frustrating! :-(

Can anyone point me in the right direction?

And then I can get to grips with my work.

tia
Bill

 

[A.B., Khalid]

I downlaoded and installed
http://www.python.org/ftp/python/2.4.1/python-2.4.1.msi

I'm trying to build an extension using SWIG 1.3.24 and the linker needs
python24_d.lib (I do not have the DLL either). I've not found it in any of
the
downloads.

So I tried to download the source to build it myself. Of
http://www.python.org/ftp/python/2.4.1/Python-2.4.1.tar.bz2 and
http://www.python.org/ftp/python/2.4.1/Python-2.4.1.tgz, WinZip (9.0 SR1)
just says "Error reading header after processing 0 entries".

Additionally, I've had no joy downloading the unzipper
(ftp://sources.redhat.com/pub/bzip2/v102/bzip2-102-x86-win32.exe) from the
site cited for the unzipper (http://sources.redhat.com/bzip2/). It flashed
up a
black console window momentarily.

Oh, this is sooooo frustrating! :-(

Can anyone point me in the right direction?

And then I can get to grips with my work.

tia
Bill

I am no expert in MSVC6, but it sounds like maybe you need to supply
the no-debug switch in your extention setup.py file: /d NDEBUG.

In case that does not work and help on this is not forthcoming, you can
always try pyMinGW[1].


Regards,
Khalid



[1] pyMinGW:
http://jove.prohosting.com/iwave/ipython/pyMinGW.html

 

[Bill Davy]

I am no expert in MSVC6, but it sounds like maybe you need to supply
the no-debug switch in your extention setup.py file: /d NDEBUG.

In case that does not work and help on this is not forthcoming, you can
always try pyMinGW[1].


Regards,
Khalid

Hmm, that's one possibility but I really do need to keep the debugger
version going. I'm only just getting started. Any other suggestions?

 

[James Carroll]

Hi Bill,

Python 2.4 requires VC7.1 I just ran into this recently. Once I
installed VC7.1, I could easily compile the Python source to create a
debug lib.

Winzip should be able to read the python source tarball... There is
one trick though. Once you download it, it might get renamed to
python.tar.gz.tar and the trick is to rename the file's extension to
..tar.gz or (my preference) .tgz.

If it really is a bzip2 file, then you'll need some sort of bunzip. I
use the cygnus version, but I don't remember having to do anything out
of the way for the python source.

-Jim

I am no expert in MSVC6, but it sounds like maybe you need to supply
the no-debug switch in your extention setup.py file: /d NDEBUG.

In case that does not work and help on this is not forthcoming, you can
always try pyMinGW[1].


Regards,
Khalid

Hmm, that's one possibility but I really do need to keep the debugger
version going. I'm only just getting started. Any other suggestions?

 

[Bill Davy]

Hi,
Many thanks for this.
I am constrained to use MSVC6 (customer) but will look to see if I can run
VC7.1 alongside VC6.
However, I am still unable to decompress/unpack the downloaded source files
even with their extensions amended.
Am I really the only person having this difficulty?
Hey ho,
Bill

Hi Bill,

Python 2.4 requires VC7.1 I just ran into this recently. Once I
installed VC7.1, I could easily compile the Python source to create a
debug lib.

Winzip should be able to read the python source tarball... There is
one trick though. Once you download it, it might get renamed to
python.tar.gz.tar and the trick is to rename the file's extension to
..tar.gz or (my preference) .tgz.

If it really is a bzip2 file, then you'll need some sort of bunzip. I
use the cygnus version, but I don't remember having to do anything out
of the way for the python source.

-Jim

I am no expert in MSVC6, but it sounds like maybe you need to supply
the no-debug switch in your extention setup.py file: /d NDEBUG.

In case that does not work and help on this is not forthcoming, you can
always try pyMinGW[1].


Regards,
Khalid

Hmm, that's one possibility but I really do need to keep the debugger
version going. I'm only just getting started. Any other suggestions?

 

[A.B., Khalid]

Okay, let me have another stap at this.

As you have probably noticed MSVC6 is no longer actively supported as
far as Python 2.4 goes. The official distribution of Python 2.4 for
Windows is built using MSVC7.1 (or whatever you wish to call it).

We are told that building C extensions with MSVC6 for use in the
official Python 2.4 (which uses the MSVCR71) is not safe, and mixing
the different runtime libraries that your extension (or my extension)
with that which official Python 2.4 uses will/might cause crashes.
Google around for details on this.

So, what to do? You seem to have four options.

1. Get and use the MSVC7.1 compiler.
2. Get and use the freely distributed MS compiler.
3. Download the Python source[1] and compile it yourself in MSVC6
(there are project files in the source to enable you to do that). Then
use your MSVC6 to create the extension.
4. Get and use MinGW and pyMinGW[2]




Regards,
Khalid




[1] Check to see if your archiever tool is working, or get the source
from CVS.

[2] pyMinGW:
http://jove.prohosting.com/iwave/ipython/pyMinGW.html

 

[Jaime Wyant]

I fight the python24_d.lib problem with swig daily. The way I got
around it was to modify swig's python configuration module. Mine was
located at

/lib/swig1.3/python/python.swg

(I'm using cygwin)

At the top, I changed

#include "python.h"

to

#ifdef _DEBUG
#undef _DEBUG
#include "python.h"
#define _DEBUG
#else
#include "python.h"
#endif

Somewhere in the includes, python uses a pragma telling the MSVC
compiler which library to link the object files against. Because
you're building a _DEBUG build, you magically get the python24_d.lib
library.

hth,
jw

 

[Bill Davy]

Thank you Khalid,



OK. (4) (compile using MSVC6) worked.



Now working through various issues to do with paths and naming (_d suffix to
root for DEBUG, _ prefix to root for SWIG, and I had not spotted that SWIG
makes Module.py that imports _Module.pyd but not _Module_d.pyd for DEBUG
builds).



I'd like to persuade IDLE to use my locally compiled version of Python
rather than the one I downloaded, and will find out how eventually.
Necessary to keep to a VC6 build of 2.4.1 throughout.



Rgds,

Bill (an inveterate top poster, I'm afraid).

 

[Bill Davy]

Thanks Jaime,

I'm making gradual progress and am finding it quite satisfying. Resorted to
tracing Python in MSVC6 to see what it was trying to IMPORT, which is a bit
heavy but thank heavens for the sources.

Had not thouight of "adapting" SWIG, and will think about it when I have a
clearer view of what I am doing (rather deeply embedded at present, trying
to get one success). I had not spotted SWIG's wrapper round a wrapper
(Module.py imports _Module.pyd) but it's reasonable except they go into
different directories. And there's the _d too, of course :-(

Many thanks for your help,

Bill

I fight the python24_d.lib problem with swig daily. The way I got
around it was to modify swig's python configuration module. Mine was
located at

/lib/swig1.3/python/python.swg

(I'm using cygwin)

At the top, I changed

#include "python.h"

to

#ifdef _DEBUG
#undef _DEBUG
#include "python.h"
#define _DEBUG
#else
#include "python.h"
#endif

Somewhere in the includes, python uses a pragma telling the MSVC
compiler which library to link the object files against. Because
you're building a _DEBUG build, you magically get the python24_d.lib
library.

hth,
jw

 

[Scott David Daniels]

Thanks Jaime,

I'm making gradual progress and am finding it quite satisfying. Resorted to
tracing Python in MSVC6 to see what it was trying to IMPORT, which is a bit
heavy but thank heavens for the sources.

You might try running python from a command window and running it "-v"
as in:

python -v prog.py -args ...

--Scott David Daniels
(e-mail address removed)

 

[Bill Davy]

Hi Scott,
Nice idea. Tried that but no more information about where the file was
(not) found (see below).
But many thanks for a useful flag. I did not see them in the documentation.
What should I be lkooking for? [StopPres: Ah ha -h why did I not think of
that?]
Bill

# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# C:\Python24\lib\site.pyc matches C:\Python24\lib\site.py
import site # precompiled from C:\Python24\lib\site.pyc
# C:\Python24\lib\os.pyc matches C:\Python24\lib\os.py
import os # precompiled from C:\Python24\lib\os.pyc
import nt # builtin
# C:\Python24\lib\ntpath.pyc matches C:\Python24\lib\ntpath.py
import ntpath # precompiled from C:\Python24\lib\ntpath.pyc
# C:\Python24\lib\stat.pyc matches C:\Python24\lib\stat.py
import stat # precompiled from C:\Python24\lib\stat.pyc
# C:\Python24\lib\UserDict.pyc matches C:\Python24\lib\UserDict.py
import UserDict # precompiled from C:\Python24\lib\UserDict.pyc
# C:\Python24\lib\copy_reg.pyc matches C:\Python24\lib\copy_reg.py
import copy_reg # precompiled from C:\Python24\lib\copy_reg.pyc
# C:\Python24\lib\types.pyc matches C:\Python24\lib\types.py
import types # precompiled from C:\Python24\lib\types.pyc
# C:\Python24\lib\locale.pyc matches C:\Python24\lib\locale.py
import locale # precompiled from C:\Python24\lib\locale.pyc
import _locale # builtin
# C:\Python24\lib\codecs.pyc matches C:\Python24\lib\codecs.py
import codecs # precompiled from C:\Python24\lib\codecs.pyc
import _codecs # builtin
import encodings # directory C:\Python24\lib\encodings
# C:\Python24\lib\encodings\__init__.pyc matches
C:\Python24\lib\encodings\__ini
t__.py
import encodings # precompiled from C:\Python24\lib\encodings\__init__.pyc
# C:\Python24\lib\encodings\aliases.pyc matches
C:\Python24\lib\encodings\aliase
s.py
import encodings.aliases # precompiled from
C:\Python24\lib\encodings\aliases.py
c
# C:\Python24\lib\encodings\cp1252.pyc matches
C:\Python24\lib\encodings\cp1252.
py
import encodings.cp1252 # precompiled from
C:\Python24\lib\encodings\cp1252.pyc
# C:\Python24\lib\warnings.pyc matches C:\Python24\lib\warnings.py
import warnings # precompiled from C:\Python24\lib\warnings.pyc
# C:\Python24\lib\linecache.pyc matches C:\Python24\lib\linecache.py
import linecache # precompiled from C:\Python24\lib\linecache.pyc
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.# C:\Python24\lib\encodings\cp850.pyc matches
C:\Python24\lib\encodings\cp850.py

import encodings.cp850 # precompiled from
C:\Python24\lib\encodings\cp850.pycTraceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):

 

[Scott David Daniels]

Hi Scott,
Nice idea. Tried that but no more information about where the file was
(not) found (see below).
But many thanks for a useful flag. I did not see them in the documentation.
What should I be lkooking for? [StopPres: Ah ha -h why did I not think of
that?]

...

Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: No module named SHIP

Two common problems here:
1) There is no file *\SHIP.pyd where * is one entry of sys.path
2) The capitalization is not correct. The file lookup will succeed,
but then, when "initSHIP(void)" is hunted for in the module, no such
function will be found. It is kind of surprising to get the funny
mix of case-sensitivity and case-insensitivity that results from
mixing Python and Windows. By the way, I might not even have it
right here; I simply make everything as if all tests were case-
sensitive.

--Scott David Daniels
(e-mail address removed)

 

[Bill Davy]

Traceback (most recent call last):

Two common problems here:
1) There is no file *\SHIP.pyd where * is one entry of sys.path
2) The capitalization is not correct. The file lookup will succeed,
but then, when "initSHIP(void)" is hunted for in the module, no such
function will be found. It is kind of surprising to get the funny
mix of case-sensitivity and case-insensitivity that results from
mixing Python and Windows. By the way, I might not even have it
right here; I simply make everything as if all tests were case-
sensitive.

--Scott David Daniels
(e-mail address removed)

And also Python may be looking for SHIP_d.pyd too (as it is Windows Debug
version).

Anyway, I am making prgress (but see new thread on IDLE)

Thanks for the help.

Bill