Re: [Mingw-w64-public] 64bit Python bindings for libftdi1-1.0 with MinGW-w64
On 2/19/2013 08:12, Xiaofan Chen wrote:
On Tue, Feb 19, 2013 at 6:12 AM, JonY jo...@users.sourceforge.net wrote:
On 2/18/2013 22:56, Xiaofan Chen wrote:
Ref:
http://developer.intra2net.com/mailarchive/html/libftdi/2013/msg00137.html
I am trying to build the 64bit Python (2.7.3 and 3.3) bindings for
libftdi1-1.0 ( http://www.intra2net.com/en/developer/libftdi/download.php )
with MinGW-w64 (Ruben personal build 4.7.2 release).
But somehow it does not work.
I am trying using the instructions here.
http://stackoverflow.com/questions/11182765/how-can-i-build-my-c-extensions-with-mingw-w64-in-python
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.
c:\work\libftdi\libftdi1-1.0\examples\pythonpython
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
on win
32
Type help, copyright, credits or license for more information.
import ftdi1 as ftdi
Traceback (most recent call last):
File stdin, line 1, in module
File C:\python27\lib\site-packages\ftdi1.py, line 30, in module
_ftdi1 = swig_import_helper()
File C:\python27\lib\site-packages\ftdi1.py, line 26, in
swig_import_helper
_mod = imp.load_module('_ftdi1', fp, pathname, description)
ImportError: DLL load failed: The specified procedure could not be found.
Use dependency walker to find out if you really have a _ftdi1 export.
Seems to be fine.
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.
signature.asc
Description: OpenPGP digital signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] 64bit Python bindings for libftdi1-1.0 with MinGW-w64
On Tue, Feb 19, 2013 at 5:22 PM, JonY jo...@users.sourceforge.net wrote: On 2/19/2013 08:12, Xiaofan Chen wrote: On Tue, Feb 19, 2013 at 6:12 AM, JonY jo...@users.sourceforge.net wrote: On 2/18/2013 22:56, Xiaofan Chen wrote: Ref: http://developer.intra2net.com/mailarchive/html/libftdi/2013/msg00137.html I am trying to build the 64bit Python (2.7.3 and 3.3) bindings for libftdi1-1.0 ( http://www.intra2net.com/en/developer/libftdi/download.php ) with MinGW-w64 (Ruben personal build 4.7.2 release). But somehow it does not work. I am trying using the instructions here. http://stackoverflow.com/questions/11182765/how-can-i-build-my-c-extensions-with-mingw-w64-in-python 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. -- Xiaofan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] 64bit Python bindings for libftdi1-1.0 with MinGW-w64
There are mingw pythons around if you want to try that route? On 19 Feb 2013 13:45, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Feb 19, 2013 at 5:22 PM, JonY jo...@users.sourceforge.net wrote: On 2/19/2013 08:12, Xiaofan Chen wrote: On Tue, Feb 19, 2013 at 6:12 AM, JonY jo...@users.sourceforge.net wrote: On 2/18/2013 22:56, Xiaofan Chen wrote: Ref: http://developer.intra2net.com/mailarchive/html/libftdi/2013/msg00137.html I am trying to build the 64bit Python (2.7.3 and 3.3) bindings for libftdi1-1.0 ( http://www.intra2net.com/en/developer/libftdi/download.php ) with MinGW-w64 (Ruben personal build 4.7.2 release). But somehow it does not work. I am trying using the instructions here. http://stackoverflow.com/questions/11182765/how-can-i-build-my-c-extensions-with-mingw-w64-in-python 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. -- Xiaofan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] 64bit Python bindings for libftdi1-1.0 with MinGW-w64
2013/2/19 Xiaofan Chen xiaof...@gmail.com On Tue, Feb 19, 2013 at 5:22 PM, JonY jo...@users.sourceforge.net wrote: On 2/19/2013 08:12, Xiaofan Chen wrote: On Tue, Feb 19, 2013 at 6:12 AM, JonY jo...@users.sourceforge.net wrote: On 2/18/2013 22:56, Xiaofan Chen wrote: Ref: http://developer.intra2net.com/mailarchive/html/libftdi/2013/msg00137.html I am trying to build the 64bit Python (2.7.3 and 3.3) bindings for libftdi1-1.0 ( http://www.intra2net.com/en/developer/libftdi/download.php ) with MinGW-w64 (Ruben personal build 4.7.2 release). But somehow it does not work. I am trying using the instructions here. http://stackoverflow.com/questions/11182765/how-can-i-build-my-c-extensions-with-mingw-w64-in-python 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. Note official Python 2.7 uses MSVC2008 and Python 3.x use MSVC2010. Two things: 1. You're sure you have installed the MSVC++ redistributables that Python needs? Check with Dependency Walker to be sure 2. Forget everythin I said above, and add -DMS_WIN64 to your module compilation. This will fix all of your problems (it fixed mine when building gdb with Python support). Sorry for the delay in helpful response, I just remembered I faced the same problems before. Note that no manual editing of def files should be done. Cheers, Ruben -- Xiaofan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] TLS support fixes
Hi all, please find two patches to fix/improve TLS support in mingw-w64-crt attached. The first diff is an actual bug fix; it corrects the TLS start address written to the TLS dictionary (_tls_used). It is used to determine the size and initial contents of the TLS area for new threads. If it does not point to the start of the section, all the initial data will be off (as well as the size), because the Windows TLS model uses offsets relative to the section start (@SECREL). The second diff is just a small optimization, it moves the TLS dictionary out of the .tls section, as it isn't itself thread-specific data. The current situation seems to work fine as it is just read-only data anyway, but it is confusing while debugging and also wastes a few bytes of TLS memory. Using the patches, TLS works fine in our (LDC) compiler. I'm not quite sure what the best way to add a test case for this is, as the MinGW GCC uses the emutls infrastructure instead of native Windows TLS for __thread variables, and a test case in asm seems a bit cumbersome to handle. Also, please let me know if there is another preferred method to submit patches. David 0001-fix-tls-start-offset.diff Description: Binary data 0002-do-not-place-tls-used-in-tls-section.diff Description: Binary data -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] TLS support fixes
Hi, well, - (ULONG_PTR) _tls_start+1, (ULONG_PTR) _tls_end, + (ULONG_PTR) _tls_start, (ULONG_PTR) _tls_end, looks to me wrong due we always have one pointer-size allocated in TLS. shouldn't be the required fix as the following here? - (ULONG_PTR) _tls_start+1, (ULONG_PTR) _tls_end, + (ULONG_PTR) (_tls_start+1), (ULONG_PTR) _tls_end, Cheers, Kai 2013/2/19 David Nadlinger c...@klickverbot.at: Hi all, please find two patches to fix/improve TLS support in mingw-w64-crt attached. The first diff is an actual bug fix; it corrects the TLS start address written to the TLS dictionary (_tls_used). It is used to determine the size and initial contents of the TLS area for new threads. If it does not point to the start of the section, all the initial data will be off (as well as the size), because the Windows TLS model uses offsets relative to the section start (@SECREL). The second diff is just a small optimization, it moves the TLS dictionary out of the .tls section, as it isn't itself thread-specific data. The current situation seems to work fine as it is just read-only data anyway, but it is confusing while debugging and also wastes a few bytes of TLS memory. Using the patches, TLS works fine in our (LDC) compiler. I'm not quite sure what the best way to add a test case for this is, as the MinGW GCC uses the emutls infrastructure instead of native Windows TLS for __thread variables, and a test case in asm seems a bit cumbersome to handle. Also, please let me know if there is another preferred method to submit patches. David -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] TLS support fixes
Hi Kai, On Tue, Feb 19, 2013 at 7:27 PM, Kai Tietz ktiet...@googlemail.com wrote: - (ULONG_PTR) _tls_start+1, (ULONG_PTR) _tls_end, + (ULONG_PTR) _tls_start, (ULONG_PTR) _tls_end, looks to me wrong due we always have one pointer-size allocated in TLS. shouldn't be the required fix as the following here? - (ULONG_PTR) _tls_start+1, (ULONG_PTR) _tls_end, + (ULONG_PTR) (_tls_start+1), (ULONG_PTR) _tls_end, I'm afraid I can only repeat what I already wrote before: _tls_start must point to the start of the TLS section. To illustrate this, consider the following small program that prints (or rather, should print) cafebabe, deadbeef, with the hex values read from TLS variables: --- .section .text.startup,x .globl _main .def _main; .scl 2; .type 32; .endef _main: subl $12, %esp movl __tls_index, %eax movl %fs:44, %ecx movl (%ecx,%eax,4), %ecx movl _tlsVar1@SECREL32(%ecx), %eax movl _tlsVar2@SECREL32(%ecx), %ecx movl %ecx, 8(%esp) movl %eax, 4(%esp) movl $_.str, (%esp) call _printf xorl %eax, %eax addl $12, %esp ret .section .tls$,w .globl _tlsVar1 .align 4 _tlsVar1: .long 0xcafebabe .globl _tlsVar2 .align 4 _tlsVar2: .long 0xdeadbeef .section .rdata,dr _.str: .asciz %x, %x\n --- Note how in the Windows TLS model, the base address is first computed based on __tls_index and %fs:44, and then the offset of the respective variable from the beginning of the section it is in (.tls) is added. Now, if the start address entry of the TLS info struct does not point to the beginning of the section, it is obvious that the offsets obtained via the SECREL relecation will be off, as Windows will use the given range to initialize the TLS area for new threads. With my patch, the above program produces the correct output. Without it, it will rather print efcafeba, deadbe (or similar, didn't check against an old libmingw32.a). David -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
