Asp Forum - Python, Reportlabs, Pil and Windows 7 (64bit

Astley Le Jasper

3/11/2010 1:56:00 PM

I have a Windows 7 (64bit AMD) machine and am having quite a lot of
problems installing Reportlabs and Pil. I wondered if anyone else has
had the same issues and what the best way of dealing with it.

So far I've tried:

1. Reportlabs / Pil 32 installers - I've tried using these but they
can't find python. I also tried registering Python (http://e...
zone/python-register.htm) but this also fails.
2. Reportlabs / Pil Source - I downloaded each of these and tried to
do a "python setup.py install". However, both complain that they can't
find "vcvarsall.bat". I've done some checking and it's because the
compiler isn't present. Everyone is suggesting downloading Visual
Studio Express C++, but this only comes with the 32bit compiler. There
seems to be quite a lot of work to get 64bit VSE working on a 64bit
machine (http://jenshuebel.wordpress.com/2009/02/12/visu...
express-edition-and-64-bit-targets/).

But before I start down that path, I wondered if anyone had any advice
(.... and no I don't mean suggesting I swap to Linux).

ALJ

13 Answers

Robin Becker

3/11/2010 4:29:00 PM

On 11/03/2010 13:55, Astley Le Jasper wrote:
> I have a Windows 7 (64bit AMD) machine and am having quite a lot of
> problems installing Reportlabs and Pil. I wondered if anyone else has
> had the same issues and what the best way of dealing with it.
>
> So far I've tried:
>
> 1. Reportlabs / Pil 32 installers - I've tried using these but they
> can't find python. I also tried registering Python (http://e...
> zone/python-register.htm) but this also fails.
> 2. Reportlabs / Pil Source - I downloaded each of these and tried to
> do a "python setup.py install". However, both complain that they can't
> find "vcvarsall.bat". I've done some checking and it's because the
> compiler isn't present. Everyone is suggesting downloading Visual
> Studio Express C++, but this only comes with the 32bit compiler. There
> seems to be quite a lot of work to get 64bit VSE working on a 64bit
> machine (http://jenshuebel.wordpress.com/2009/02/12/visu...
> express-edition-and-64-bit-targets/).
>
> But before I start down that path, I wondered if anyone had any advice
> (.... and no I don't mean suggesting I swap to Linux).
>
> ALJ

Hi,

you might get more assistance on the reportlab users mailing list at

http://two.pairlist.net/mailman/listinfo/repor...

We do have users that run both reportlab & pil on 64 bit linux architectures,
but I don't think I have ever compiled any of the extensions for 64bit windows.
The vcvarsall.bat reference is the distutils package desperately looking for a
suitable compiler (and not finding it).

Perhaps some expert on the python list knows which versions of VS support 64bit;
I do have VS 2005/2008 etc, but I'll probably need to set up a 64bit machine to
see if they will install on a 64bit architecture.
--
Robin Becker

Martin v. Loewis

3/11/2010 6:00:00 PM

>> I have a Windows 7 (64bit AMD) machine

This is somewhat imprecise: is it
a) that your CPU is AMD64, and thus supports 64-bit mode, or
b) that *in addition*, your Windows 7 installation is a 64-bit
installation, or
c) that *in addition*, your Python installation is also a 64-bit
installation.

Unless you have a specific need for 64-bit mode, I recommend that you
use the 32-bit version of Windows (unless you have more than 4GB of
main memory), and (even if you have a 64-bit Windows) you install the
32-bit version of Python on it (unless you have the need to access more
than 2GB of objects in your Python applications.

>> 1. Reportlabs / Pil 32 installers - I've tried using these but they
>> can't find python. I also tried registering Python (http://e...
>> zone/python-register.htm) but this also fails.

Install the 32-bit version of Python, and these installers should work fine.

> Perhaps some expert on the python list knows which versions of VS
> support 64bit; I do have VS 2005/2008 etc, but I'll probably need to set
> up a 64bit machine to see if they will install on a 64bit architecture.

For Python 2.6 and later, use VS 2008. This comes with an AMD64
compiler. You technically don't need a 64-bit Windows, as it supports
cross-compilation (but you would need a 64-bit Windows to test it).

I personally build Python on a 32-bit machine, and move the MSI to a
64-bit machine for testing.

Regards,
Martin

Astley Le Jasper

3/11/2010 8:57:00 PM

@Robin
Thanks. I thought that this seemed to be a general python thing
because it was effecting both installs. However, after also reading
Martin's comments ...

@Martin
> This is somewhat imprecise: is it
> a) that your CPU is AMD64, and thus supports 64-bit mode, or
> b) that *in addition*, your Windows 7 installation is a 64-bit
> installation, or
> c) that *in addition*, your Python installation is also a 64-bit
> installation.
>
> Unless you have a specific need for 64-bit mode, I recommend that you
> use the 32-bit version of Windows (unless you have more than 4GB of
> main memory), and (even if you have a 64-bit Windows) you install the
> 32-bit version of Python on it (unless you have the need to access more
> than 2GB of objects in your Python applications.

Sorry. I have Windows 7 (64-bit) installed on a machine with an AMD
cpu (which supports 64-bit mode), with a 64-bit version of
(Activestate) python 2.6 .... although I didn't realise the later
until I looked just now.

> Install the 32-bit version of Python, and these installers should work fine.
Well, I uninstalled the 64-bit version and the installers did indeed
work.

I’m sorry everyone. I didn’t realise I had installed the 64-bit
version of Python. Well, at least someone else might find have the
same problem. But I think that there is going to be a bit of a rough
patch as everyone moves over to 64-bit.

ALJ

Martin v. Loewis

3/12/2010 7:32:00 AM

> I?m sorry everyone. I didn?t realise I had installed the 64-bit
> version of Python. Well, at least someone else might find have the
> same problem. But I think that there is going to be a bit of a rough
> patch as everyone moves over to 64-bit.

Expect that move to take a few more years. 64-bit CPUs were introduced
more than ten years ago (e.g. Alpha, in 1992), and only slowly reach
"the masses". People typically still don't have more than 4GiB of memory
in their desktop PCs or laptops, so users who do install 64-bit
operating systems on such hardware are still early adaptors.

Regards,
Martin

Robin Becker

3/12/2010 10:17:00 AM

Following the information from MvL I will try and get the 2.6 pyds built for
amd64, I see that there's a cross platform compile technique for distutils, but
am not sure if it applies to bdist_winexe etc etc. I'll have a go at this next week.
--
Robin Becker

Robin Becker

3/12/2010 11:40:00 AM

On 11/03/2010 18:00, Martin v. Loewis wrote:
>
>>> I have a Windows 7 (64bit AMD) machine
.......
>
>> Perhaps some expert on the python list knows which versions of VS
>> support 64bit; I do have VS 2005/2008 etc, but I'll probably need to set
>> up a 64bit machine to see if they will install on a 64bit architecture.
>
> For Python 2.6 and later, use VS 2008. This comes with an AMD64
> compiler. You technically don't need a 64-bit Windows, as it supports
> cross-compilation (but you would need a 64-bit Windows to test it).
>
> I personally build Python on a 32-bit machine, and move the MSI to a
> 64-bit machine for testing.
>

OK I've got the VC2008 64bit tools installed on my 32bit build platform, but I'm
getting build errors because of missing libraries. I assume that's because I
don't have the python amd64 runtime libraries/dlls etc etc since the errors are
looking like this

_rl_accel.obj : error LNK2019: unresolved external symbol __imp_Py_FindMethod
referenced in function Box_getattr
_rl_accel.obj : error LNK2019: unresolved external symbol __imp_PyObject_Init
referenced in function Box
_rl_accel.obj : error LNK2019: unresolved external symbol __imp_PyObject_Malloc
referenced in function Box
_rl_accel.obj : error LNK2019: unresolved external symbol __imp_PyList_Type
referenced in function BoxList_init
_rl_accel.obj : error LNK2019: unresolved external symbol __imp_Py_FatalError
referenced in function init_rl_accel
_rl_accel.obj : error LNK2019: unresolved external symbol __imp_PyType_Ready
referenced in function init_rl_accel
_rl_accel.obj : error LNK2019: unresolved external symbol __imp_PyType_Type
referenced in function init_rl_accel
_rl_accel.obj : error LNK2019: unresolved external symbol
__imp_PyModule_AddObject referenced in function init_rl_accel
_rl_accel.obj : error LNK2019: unresolved external symbol
__imp_PyErr_NewException referenced in function init_rl_accel
_rl_accel.obj : error LNK2019: unresolved external symbol
__imp_Py_InitModule4_64 referenced in function init_rl_accel
build\lib.win-amd64-2.6\_rl_accel.pyd : fatal error LNK1120: 69 unresolved externals

I assume I can get those from a working Python amd64 install and stuff on one of
the compiler paths somehow.
--
Robin Becker

Robin Becker

3/12/2010 11:40:00 AM

Robin Becker

3/12/2010 3:44:00 PM

On 12/03/2010 11:40, Robin Becker wrote:
.........
>
> I assume I can get those from a working Python amd64 install and stuff
> on one of the compiler paths somehow.

Not sure if this is a bug; I dug around a bit and find that because of the cross
compilation distutils is supposed to add an extra library path with the name
PCbuild\AMD64 when doing x86-->amd64 cross builds.

I tried copying the 2.6.4 amd64 libs/dlls etc etc into c:\python26\PCbuild\AMD64
and reran my cross build

c:\python26\python setup.py build --plat-name=win-amd64

however, that still gives linker import errors.

Looked in the output I see this

> C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\x86_amd64\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\python26
> \libs /LIBPATH:C:\python26\PCbuild\amd64 /EXPORT:init_rl_accel build\temp.win-amd64-2.6\Release\_rl_accel.obj /OUT:build
> \lib.win-amd64-2.6\_rl_accel.pyd /IMPLIB:build\temp.win-amd64-2.6\Release\_rl_accel.lib /MANIFESTFILE:build\temp.win-amd
> 64-2.6\Release\_rl_accel.pyd.manifest
> Creating library build\temp.win-amd64-2.6\Release\_rl_accel.lib and object build\temp.win-amd64-2.6\Release\_rl_accel
> .exp
> _rl_accel.obj : error LNK2019: unresolved external symbol __imp_PyNumber_Int referenced in function _parseSequenceInt
> _rl_accel.obj : error LNK2019: unresolved external symbol __imp_PySequence_GetItem referenced in function _parseSequence

that looks wrong because I'm using 32 bit python to do the build and

/LIBPATH:C:\python26\libs /LIBPATH:C:\python26\PCbuild\amd64

means that the 32 bit libraries are first. Running the linker command by itself
(without the 32bit libs in the command) works fine ie

> C:\ux\PydBuilder\rl_addons\rl_accel>"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\x86_amd64\link.exe" /DLL /nolog
> o /INCREMENTAL:NO /LIBPATH:C:\python26\PCbuild\amd64 /EXPORT:init_rl_accel build\temp.win-amd64-2.6\Release\_rl_accel.ob
> j /OUT:build\lib.win-amd64-2.6\_rl_accel.pyd /IMPLIB:build\temp.win-amd64-2.6\Release\_rl_accel.lib /MANIFESTFILE:build\
> temp.win-amd64-2.6\Release\_rl_accel.pyd.manifest
> Creating library build\temp.win-amd64-2.6\Release\_rl_accel.lib and object build\temp.win-amd64-2.6\Release\_rl_accel
> .exp

seems to work fine and produce a pyd in build\lib.win-amd64-2.6
--
Robin Becker

Robin Becker

3/12/2010 3:44:00 PM

Martin v. Loewis

3/12/2010 7:30:00 PM

> Not sure if this is a bug

I think it is. It seems that the cross-build support in msvc9compiler
has been tested only in a build tree of Python (where there is no Libs
directory).

For released copies of Python, I could change that to distribute the
AMD64 pythonXY.lib in libs/amd64. [FWIW, I'm still puzzled why I ship
the import libraries of all the pyd files as well - I can't see a reason
other than tradition]. Then, distutils should change to look it up there.

Regards,
Martin

comp.lang.python

Python, Reportlabs, Pil and Windows 7 (64bit

Astley Le Jasper

Robin Becker

Martin v. Loewis

Astley Le Jasper

Martin v. Loewis

Robin Becker

Robin Becker

Robin Becker

Robin Becker

Robin Becker

Martin v. Loewis

x Login to ForumsZone