Python, Reportlabs, Pil and Windows 7 (64bit)

A

Astley Le Jasper

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://effbot.org/
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/visual-c-2008-
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
 
R

Robin Becker

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://effbot.org/
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/visual-c-2008-
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/reportlab-users

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.
 
M

Martin v. Loewis

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.

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
 
A

Astley Le Jasper

@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
 
M

Martin v. Loewis

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
 
R

Robin Becker

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.
 
R

Robin Becker

.......

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.
 
R

Robin Becker

.......

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.
 
R

Robin Becker

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
 
R

Robin Becker

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
 
M

Martin v. Löwis

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
 
R

Robin Becker

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).

This minor patch seems to fix the problem for me (using a PCBuild folder
parallel to libs)

C:\Python\Lib\distutils\command>diff build_ext.py.orig build_ext.py
207c207,209
< self.library_dirs.append(new_lib)
---
> self.library_dirs.insert(0,new_lib)
> else:
> self.library_dirs.append(new_lib)
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.
........

Just checked and all the pyd's seem only to export the xxx_init functions
(sometimes there are two in the pyd) so the .libs do seem a bit redundant.
 
A

Astley Le Jasper

Hi Robin,

It looks like you've been busy. I'm sorry but you are well over my
head at the moment!

:)

If you need me to test an install then I'd be happy to help. However,
I just received an email from Christoph Gohlke saying:

" ... There are 64 bit versions of Reportlab and PIL for Python 2.6
for Windows available at http://www.lfd.uci.edu/~gohlke/pythonlibs/
...."

Regards

Neil
 
D

DreiJane

Hello,

i've used reportlabs over two years now and was content with its
quality. These days i have turned to cairo and can only recommend to
do so: It is still easier to use (than the well-designed reportlabs
tools) and an engine working in a lot of other software too, for
example firefox.

Reasons for this: reportlabs do not even answer question about the
date to upgrade to Python3. Since Platypus isn't complete, i had to do
a lot with the primitves in the canvas object after all - that part of
my code got even shorter with cairo. For me - working with pygtk -
that spares two installations also.

To repear myself: I love cairo.

Regards, Joost
 

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,901
Latest member
Noble71S45

Latest Threads

Top