Prev: EOFError: EOF when reading a line
Next: Insert missing keys using defaultdict
From: Robin Becker on 12 Mar 2010 05:16
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
From: Robin Becker on 12 Mar 2010 06:40
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
From: Robin Becker on 12 Mar 2010 10:44
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
From: Martin v. Löwis on 12 Mar 2010 14:29
> 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
From: Robin Becker on 15 Mar 2010 05:58
On 12/03/2010 19:29, "Martin v. L�wis" wrote:
>> 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).

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.

--
Robin Becker

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: EOFError: EOF when reading a line
Next: Insert missing keys using defaultdict