There are mingw pythons around if you want to try that route?

On 19 Feb 2013 13:45, "Xiaofan Chen" <> wrote:
On Tue, Feb 19, 2013 at 5:22 PM, JonY <> wrote:
> On 2/19/2013 08:12, Xiaofan Chen wrote:
>> On Tue, Feb 19, 2013 at 6:12 AM, JonY <> wrote:
>>> On 2/18/2013 22:56, Xiaofan Chen wrote:
>>>> Ref:
>>>> I am trying to build the 64bit Python (2.7.3 and 3.3) bindings for
>>>> libftdi1-1.0 ( )
>>>> with MinGW-w64 (Ruben personal build 4.7.2 release).
>>>> But somehow it does not work.
>>>> I am trying using the instructions here.
>>>> For 64bit Python 2.7.3, I did the following.
>>>> 1) gendef.exe python27.dll
>>>> 2) dlltool.exe --dllname python27.dll --def python27.def --output-lib
>>>> libpython27.a
>>>> 3) Copy libpython27.a to C:\Python27\libs
>>>> Strangely, gendef has already used Py_InitModule4_64 but I need
>>>> to rename it back to Py_InitModule4 to get the Python binding build
>>>> successfully.
>>>> But the resultant Python bindings do not work. Just FYI,
>>>> 32bit Python binding works very well but I do not need
>>>> to use gendef and dlltool there since the default 32bit
>>>> Python windows binaries already provide the import
>>>> library libpython27.a.
>>> That is because your def don't match the DLL, you just
>>> messed with it.
>> The problem is that if I do not change the def file, I will
>> have the following compile error.
> That is because you just made up your own symbol, there was no such
> symbol in the DLL. Changing the def file by hand is one way to cause
> programs to fail when linked to the import library.
> You should ask a python specific list for help on the Python programming
> language or Swig for help on Swig.
> I don't think this is mingw-w64 related anymore.

Fair enough. For now I will try to patch libftdi1 to build under
MSVC 2012 and see if I can get the 64bit Python binding build
under VS2012.


Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Mingw-w64-public mailing list