Re: [Mingw-w64-public] Using Python and Mingw64
Hi Ruben. It would be great to have recruit you to the cause to get these merged. My experience in that regard has been a bit frustrating. I think the patches are split up reasonably, except for the huge ones from Roumen Petrov. Due to Alexey's mingwbuilds efforts, Qt 5.0.1 use this Python for their gdb. On bugs.python.org, the relevant numbers - last time I looked - were 3754 3871 16235 16291 and 16292. Roumen said he would split his patches up and resubmit but I've been too busy to track this recently. If you want commit access to my github project let me know: https://github.com/mingwandroid/crucifixion-freedom On 14 Mar 2013 15:28, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: Never mind, I found these: https://github.com/niXman/mingw-builds/tree/master/patches/Python-3.3.0 I'll see if I can get these sorted out and stir the Python devs :) Ruben 2013/3/14 Ruben Van Boxem vanboxem.ru...@gmail.com 2013/3/13 Ray Donnelly mingw.andr...@gmail.com You could use my Python if you want: https://mingw-and-ndk.googlecode.com/files/python-2.7.3-win64.7z https://mingw-and-ndk.googlecode.com/files/python-2.7.3-win32.7z They were compiled using MinGW-w64 compilers. The mingwbuilds project also includes Python binaries built from the same patches. Have you considered pushing these upstream to the Python devs? Reading the build python with mingw bug report ( http://bugs.python.org/issue3871) I see the devs willing to accept the changes, if split up properly. Now that I have switched to Python for my scientific stuff, it may be interesting to be able to compile Python myself. Could you give me a link to the patches used to build Python? Are there Python 3.x patches as well? Thanks, Ruben On Wed, Mar 13, 2013 at 12:15 PM, Theuns Heydenrych theunsheydenr...@gmail.com wrote: I feel that i am very near the point that it will work, but don't know what else to do. Any other suggestions? On Wed, Mar 13, 2013 at 9:52 AM, Václav Šmilauer e...@doxos.eu wrote: On 13/03/13 07:17, Theuns Heydenrych wrote: Hi, I know this is not a Python mailing list, but i am desperate. Someone in StackOverflow I am compiling Sip and PyQt from source using Mingw64 and Python 2.7.3 64bit. Python binaries is installed via downloaded installer, and is build with MSVC. I went through the exercise of making a libpython27.a file. Sip build successfully and work when used in a python console when using the following script from sip import * and PyQt build successfully , but fails with a Python stop working Windows7 dialog , when the following script is used in the python console. from PyQt4.Qt import * How do i debug this? Is it because Python is build with MSVC? Is it ok, to build things like Sip and PyQt with Mingw and gcc and it link against a MSVC Python27.dll? Hi, this is a recurrent topic unfortunately. You can built extensions to MSVC-compiled python with mingw, but the problem is the MSVC runtime you link to - msvcrt or msvcr90 etc. See my post http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/6306 (and the rest of that thread) for solution: change the MSVC dll disutils link to. I did build sip and pyqt4 (among others) successfully, it works flawlessly. (Building SIP was tricky with msys shell a bit.) You might want to check http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/6511 - there are build scripts and patches in the attachment which I used. http://bugs.python.org/issue16472 is upstream bug for this. HTH, Vaclav -- 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_mar ___ 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_mar ___ 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_mar ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Using Python and Mingw64
I think it would be great if patches will be merged in Python tree and we can build Python with mingw without this big list of patches. I can help with splitting too some later when finish some work on MSYS2. 15.03.2013, в 11:37, Ray Donnelly mingw.andr...@gmail.com написал(а): Hi Ruben. It would be great to have recruit you to the cause to get these merged. My experience in that regard has been a bit frustrating. I think the patches are split up reasonably, except for the huge ones from Roumen Petrov. Due to Alexey's mingwbuilds efforts, Qt 5.0.1 use this Python for their gdb. On bugs.python.org, the relevant numbers - last time I looked - were 3754 3871 16235 16291 and 16292. Roumen said he would split his patches up and resubmit but I've been too busy to track this recently. If you want commit access to my github project let me know: https://github.com/mingwandroid/crucifixion-freedom On 14 Mar 2013 15:28, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: Never mind, I found these: https://github.com/niXman/mingw-builds/tree/master/patches/Python-3.3.0 I'll see if I can get these sorted out and stir the Python devs :) Ruben 2013/3/14 Ruben Van Boxem vanboxem.ru...@gmail.com 2013/3/13 Ray Donnelly mingw.andr...@gmail.com You could use my Python if you want: https://mingw-and-ndk.googlecode.com/files/python-2.7.3-win64.7z https://mingw-and-ndk.googlecode.com/files/python-2.7.3-win32.7z They were compiled using MinGW-w64 compilers. The mingwbuilds project also includes Python binaries built from the same patches. Have you considered pushing these upstream to the Python devs? Reading the build python with mingw bug report (http://bugs.python.org/issue3871) I see the devs willing to accept the changes, if split up properly. Now that I have switched to Python for my scientific stuff, it may be interesting to be able to compile Python myself. Could you give me a link to the patches used to build Python? Are there Python 3.x patches as well? Thanks, Ruben On Wed, Mar 13, 2013 at 12:15 PM, Theuns Heydenrych theunsheydenr...@gmail.com wrote: I feel that i am very near the point that it will work, but don't know what else to do. Any other suggestions? On Wed, Mar 13, 2013 at 9:52 AM, Václav Šmilauer e...@doxos.eu wrote: On 13/03/13 07:17, Theuns Heydenrych wrote: Hi, I know this is not a Python mailing list, but i am desperate. Someone in StackOverflow I am compiling Sip and PyQt from source using Mingw64 and Python 2.7.3 64bit. Python binaries is installed via downloaded installer, and is build with MSVC. I went through the exercise of making a libpython27.a file. Sip build successfully and work when used in a python console when using the following script from sip import * and PyQt build successfully , but fails with a Python stop working Windows7 dialog , when the following script is used in the python console. from PyQt4.Qt import * How do i debug this? Is it because Python is build with MSVC? Is it ok, to build things like Sip and PyQt with Mingw and gcc and it link against a MSVC Python27.dll? Hi, this is a recurrent topic unfortunately. You can built extensions to MSVC-compiled python with mingw, but the problem is the MSVC runtime you link to - msvcrt or msvcr90 etc. See my post http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/6306 (and the rest of that thread) for solution: change the MSVC dll disutils link to. I did build sip and pyqt4 (among others) successfully, it works flawlessly. (Building SIP was tricky with msys shell a bit.) You might want to check http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/6511 - there are build scripts and patches in the attachment which I used. http://bugs.python.org/issue16472 is upstream bug for this. HTH, Vaclav -- 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_mar ___ 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_mar ___ 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
Re: [Mingw-w64-public] Using Python and Mingw64
ok, i just want to confirm.
I patched the cygwinccompiler.py file to /return ['msvcr90'] /(line
77) when /get_msvcr()/ is called.
So if a build the Sip.pyd with mingw, and inspect the result in
DendencyWalker I should see that Sip.pyd depended on MSVCR90 and
not MSVCRTL ?
Because after the patches and a rebuild Sip is still build
with MSVCRTL, it does not feel right, considering all the patches made?
Well, it did not feel right to me either, that's why I filed bugs about
it over at python.org, but it was the way everything worked for me
without crashes.
I have noticed that further down the file it looks like
Mingw32CCompiler class is commented out, should it be like this?
on line 343 /# class Mingw32CCompiler/
Also line 339 looked like this
/self.dll_libraries = [] # get_msvcr()/
I changed it to this
/self.dll_libraries = get_msvcr()/
Is it correct?
Well, I think patch does the right thing, so if it returns nothing, it
works (at least here). I don't remember all my iterations trying to sort
that out, but this is the result which I use. I think returning msvc90
worked as well, but it was actually not necessary (IIRC mingw links to
that one automatically, that was why it was not needed at all?). BTW be
sure to correct the path to ccache.exe, if you use it, or just delete it
altogether from there.
And regarding the pydistutils.cfg file, will it also be automatically
picked up when building Sip.pyd?
At the moment the pydistutils.cfg file is located in the
MSys/home/user folder, is this correct or should it be some
C:\Python2.7 folder?
Distutils expects that file in the home folder, though it is a bit
ambiguous under Windows for me, so I put it in both
os.path.expanduser('~') / and /c/Users/$USERNAME, to make sure. You can
try to delete one and see which one is actually used.
One last thing, how do i know python is using the Mingw32CCompiler
class, is there somehow i can debug/output, to confirm it does use
this class?
You can put something like print 500*'$' to see if it is used during
your compilation.
BTW If you want to compile in parallel, add this to your setup.py of the
compilation-hungry package: http://stackoverflow.com/a/13176803/761090 .
HTH, Vaclav
PS you don't need cc me, I am on the list :-)
--
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_mar___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Using Python and Mingw64
One other thing , i configure Sip with /python configure.py DEFINES+=MS_WIN64 -p win32-g++/ Does it change something? For me it works without MS_WIN64. (I am glad I compiled everything I needed, only occasionally rebooting to windows for a build; so I don't feel like experimenting with such flags again; and hope to stay with the versions I used for at least half a year or so...) Cheers, v. -- 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_mar___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Using Google to search MinGW-w64-public archives
On Fri, Mar 15, 2013 at 12:28 AM, Mook wrote: On 3/14/2013 8:48 AM, Earnie Boyd wrote: I've noticed some saying the SF archives search blows, here is an alternative using Google: mingw-w64-public+SearchItem+SearchItemN site:sourceforge.net/mailarchive/forum.php gmane also has a searchable archive, though I have no idea if it's better or worse than SF's search: Far better in my opinion. I like there threaded view. http://dir.gmane.org/gmane.comp.gnu.mingw.w64.general -- Earnie -- https://sites.google.com/site/earnieboyd -- 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_mar ___ 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] Prefer to use local headers over installed headers
On Fri, Mar 15, 2013 at 12:55 AM, John E. / TDM tdra...@tdragon.net wrote: On 3/14/2013 8:54 PM, NightStrike wrote: On Thu, Mar 14, 2013 at 4:22 PM, John E. / TDM tdra...@tdragon.net wrote: $(RUNTIME_SRC)/configure --build=x86_64-w64-mingw32 --enable-lib32 --enable-sdk=all --with-libraries=libmangle --with-tools=all --prefix=$(RUNTIME_STAGE) make make install If GCC or mingw-w64 introduce ABI-breaking changes (this happens often), I build a non-bootstrap GCC first in order to run this top-level mingw-w64 build before bootstrapping; otherwise I use the bootstrapped GCC. So no headers? IIUC, it's only the headers package that is screwing up. The headers seem to get built along with all the other subtrees... ? Curious... when configuring the crt, which headers is it checking for _mingw_mac.h? The soon-to-be-built ones, or the already-installed-as-part-of-the-toolchain ones? Similarly, which is it compiling against? -- 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_mar ___ 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] Prefer to use local headers over installed headers
On Mar 15 06:09, JonY wrote: On 3/14/2013 23:52, Corinna Vinschen wrote: What two build systems? It's a fairly simple patch which allows the normal user of mingw64 to build the entire source tree in a single `configure; make; make install', nothing more, nothing less. I don't understand why the unnecessary complicated 2-stage process is enforced. After having some proper sleep and looking at your patch again, I can see what you are trying to do. Please keep the changes to the top level configure, pass the -I arguments to the lower levels. None of the lower modules have any business getting too familiar with each other. I think NightStrike is already looking into this, so I shut up for now. Feel free to ping me if I I'm supposed to do something in this matter. Corinna -- 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_mar ___ 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] Prefer to use local headers over installed headers
On 3/15/2013 22:14, NightStrike wrote: Curious... when configuring the crt, which headers is it checking for _mingw_mac.h? The soon-to-be-built ones, or the already-installed-as-part-of-the-toolchain ones? Similarly, which is it compiling against? It is a sanity check, to make sure we are really building against mingw-w64 headers, not Linux headers nor mingw.org headers. 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_mar___ 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] Prefer to use local headers over installed headers
On 3/15/2013 8:14 AM, NightStrike wrote: On Fri, Mar 15, 2013 at 12:55 AM, John E. / TDM tdra...@tdragon.net wrote: The headers seem to get built along with all the other subtrees... ? Curious... when configuring the crt, which headers is it checking for _mingw_mac.h? The soon-to-be-built ones, or the already-installed-as-part-of-the-toolchain ones? Similarly, which is it compiling against? I haven't ever dug into the mingw-w64 build system to be able to answer these questions -- it's always worked, so I haven't worried about it. -John E. / TDM -- 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_mar ___ 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] Prefer to use local headers over installed headers
On Fri, Mar 15, 2013 at 3:24 PM, John E. / TDM tdra...@tdragon.net wrote: On 3/15/2013 8:14 AM, NightStrike wrote: On Fri, Mar 15, 2013 at 12:55 AM, John E. / TDM tdra...@tdragon.net wrote: The headers seem to get built along with all the other subtrees... ? Curious... when configuring the crt, which headers is it checking for _mingw_mac.h? The soon-to-be-built ones, or the already-installed-as-part-of-the-toolchain ones? Similarly, which is it compiling against? I haven't ever dug into the mingw-w64 build system to be able to answer these questions -- it's always worked, so I haven't worried about it. I have a hunch that it's working because you are building mingw-w64 with mingw-w64. If you did it with, say, mingw.org, it'd probably fail... which means, it's taking the files from the build compiler to jimmy the tests. -- 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_mar ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
