[Mingw-w64-public] Using Python and Mingw64

2013-03-13 Thread Theuns Heydenrych
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?

Regards
Theuns Heydenrych
--
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

2013-03-13 Thread Václav Šmilauer
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


[Mingw-w64-public] [patch] Prefer to use local headers over installed headers

2013-03-13 Thread Corinna Vinschen
Hi,

I'd like to resurrect a patch which has been refused last year, but
I think it's still helpful and maybe the opinions have changed a bit.

For people building just the latest mingw64-headers and mingw64-crt,
it's kind of surprising that mingw64-crt requires that the headers
are already installed.  In theory, the right thing to do should be
that mingw64-crt is build after mingw64-headers, and then prefer the
just built in-tree headers over the already installed headers.  The
below patch does that, unless the --without-headers option is set.

This should work in all typical scenarios:

- cross build gcc:

  The headers have to be build first.  At the time crt gets build,
  the in-tree headers already have been built for gcc, so they
  are nicely available for the crt build.

- native build gcc:

  The installed headers are potentially old.  Building crt with the
  latest in-tree headers is preferrable to circumnavigate potential
  bugs in the older headers.

- native mingw-only build:

  Same as above.

I can't come up with a scenario in which it would be bad to use the
in-tree headers, unless you don't build the headers, but crt only.
This should be fixable, shouldn't it?


TIA,
Corinna


* configure.ac: Add --without-headers option.  Set WITH_LOCAL_HEADERS
by default unless no parallel mingw-w64-headers directory exists.
* configure: Regenerate.
* Makefile.am: Add local header paths to sysincludes if
WITH_LOCAL_HEADERS is set.


Index: configure.ac
===
--- configure.ac(revision 5645)
+++ configure.ac(working copy)
@@ -45,6 +45,19 @@
 dnl ---
 AM_PROG_CC_C_O
 
+AC_MSG_CHECKING([whether to use the local in-tree headers])
+AC_ARG_WITH([headers],
+  [AS_HELP_STRING([--without-headers],
+[Do not use the in-tree mingw-w64 headers])],
+  [],
+  [with_headers=`test -d ${srcdir}/../mingw-w64-headers  echo yes || echo 
no`])
+AC_MSG_RESULT([$with_headers])
+AS_CASE([$with_headers],
+  [no],[],
+  [yes],[AS_VAR_SET([WITH_LOCAL_HEADERS])],
+  [AC_MSG_ERROR([invalid argument.  Must be either yes or no.])])
+AM_CONDITIONAL([WITH_LOCAL_HEADERS], [AS_VAR_TEST_SET([WITH_LOCAL_HEADERS])])
+
 AC_MSG_CHECKING([whether to build a w32api package for Cygwin])
 AC_ARG_ENABLE([w32api],
   [AS_HELP_STRING([--enable-w32api],
@@ -228,7 +241,11 @@
 #AC_FUNC_VPRINTF
 #AC_CHECK_FUNCS([alarm atexit btowc fesetround floor ftruncate gettimeofday 
isascii localeconv mbrlen memmove memset pow rint setlocale sqrt strcasecmp 
strchr strncasecmp strtoull strtoumax])
 
-AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if the 
mingw-w64 header set and the build/host option are set properly.])])
+AS_CASE([$with_headers],
+  [yes],[],
+  [AC_CHECK_HEADER([_mingw_mac.h],
+   [],
+   [AC_MSG_ERROR([Please check if the mingw-w64 header set and 
the build/host option are set properly.])])])
 
 #Warnings and errors, default level is 3
 AC_MSG_CHECKING([for warning levels])
Index: Makefile.am
===
--- Makefile.am (revision 5645)
+++ Makefile.am (working copy)
@@ -12,11 +12,17 @@
 
 #AUTOMAKE_OPTIONS = color-tests
 
+if WITH_LOCAL_HEADERS
+local_headers=-I$(abs_top_srcdir)/../mingw-w64-headers/crt 
-I$(abs_top_srcdir)/../mingw-w64-headers/include 
-I$(abs_builddir)/../mingw-w64-headers 
-I$(abs_builddir)/../mingw-w64-headers/crt
+else
+local_headers=
+endif
+sysincludes=$(local_headers)
+
 if WITHSYSROOT
-  sysincludes=-I@TARGET_SYSTEM_ROOT@/include
+  sysincludes+=-I@TARGET_SYSTEM_ROOT@/include
   withsys=--with-sysroot=@TARGET_SYSTEM_ROOT@
 else
-  sysincludes=
   withsys=
 endif
 

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

2013-03-13 Thread Theuns Heydenrych
Thank You for all the information, it really helped a lot.
But still things don't work correctly.

I had a good look at your shell script build-all.sh
I installed Python 2.7.3 64bit manually and applied the patch for python
I Compiled Sip 4.14.3 and install it.
I Compiled PyQt-win-gpl-4.9.6 and installed it.

Execute the following and get the following error:
*python*
* from PyQt4.Qt import QtCore*
*Traceback (most recent call last):*
*  File stdin, line 1, in module*
*ImportError: cannot import name QtCore*
**

I then used python -vv to see a bit more info (see
http://pastebin.com/kzttMhed ) and also inspected the QtCore.pyd with
DependencyWalker (see http://pastebin.com/GnYxZ00z ) but everything looks
fine.
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


Re: [Mingw-w64-public] Using Python and Mingw64

2013-03-13 Thread Theuns Heydenrych
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


Re: [Mingw-w64-public] Using Python and Mingw64

2013-03-13 Thread Ray Donnelly
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.

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

2013-03-13 Thread Theuns Heydenrych
Great , thanks i will give it a try.
Much obliged.


On Wed, Mar 13, 2013 at 2:33 PM, Ray Donnelly mingw.andr...@gmail.comwrote:

 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.

 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

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

2013-03-13 Thread Theuns Heydenrych
Ray, Thanks for the downloads.
When Compiling Sip i get the following error.

*C:\dev\sip-4.14.3mingw32-make
*
*mingw32-make[1]: Entering directory 'C:/dev/sip-4.14.3/sipgen'*
*makefile:29: warning: overriding recipe for target '.c.o'*
*makefile:26: warning: ignoring old recipe for target '.c.o'*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o main.o
main.c*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o transform.o
transform.c*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o gencode.o
gencode.c*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o extracts.o
extracts.c*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o export.o
export.c*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o heap.o
heap.c*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o parser.o
parser.c*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o lexer.o
lexer.c*
*g++ -mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import
-Wl,-enable-runtime-pseudo-reloc -Wl,-subsystem,console -Wl,-s -o sip.exe
main.o transform.o gencode.o extracts.o export.o heap.o parser.o lexer.o*
*
*
*mingw32-make[1]: Leaving directory 'C:/dev/sip-4.14.3/sipgen'*
*mingw32-make[1]: Entering directory 'C:/dev/sip-4.14.3/siplib'*
*makefile:29: warning: overriding recipe for target '.c.o'*
*makefile:26: warning: ignoring old recipe for target '.c.o'*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
-IC:\Python27\include\python2.7 -o siplib.o siplib.c*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
-IC:\Python27\include\python2.7 -o apiversions.o apiversions.c*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
-IC:\Python27\include\python2.7 -o descriptors.o descriptors.c*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
-IC:\Python27\include\python2.7 -o qtlib.o qtlib.c*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
-IC:\Python27\include\python2.7 -o threads.o threads.c*
*gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
-IC:\Python27\include\python2.7 -o objmap.o objmap.c*
*In file included from C:\Python27\include\python2.7/Python.h:58:0,*
* from sip.h:32,*
* from objmap.c:23:*
*C:\Python27\include\python2.7/pyport.h:232:9: error: #error This
platform's pyconfig.h needs to define PY_FORMAT_SIZE_T*
*makefile:29: recipe for target 'objmap.o' failed*
*mingw32-make[1]: *** [objmap.o] Error 1*
*mingw32-make[1]: Leaving directory 'C:/dev/sip-4.14.3/siplib'*
*makefile:3: recipe for target 'all' failed*
*mingw32-make: *** [all] Error 2*


On Wed, Mar 13, 2013 at 2:33 PM, Ray Donnelly mingw.andr...@gmail.comwrote:

 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.

 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 

Re: [Mingw-w64-public] Using Python and Mingw64

2013-03-13 Thread Ray Donnelly
Your cflags are wrong. Please run bin/python-config.sh --cflags (or
bin/python-config). You'll need to adjust the include paths.

In this instance, you are missing __USE_MINGW_ANSI_STDIO.

On Wed, Mar 13, 2013 at 1:03 PM, Theuns Heydenrych
theunsheydenr...@gmail.com wrote:
 Ray, Thanks for the downloads.
 When Compiling Sip i get the following error.

 C:\dev\sip-4.14.3mingw32-make
 mingw32-make[1]: Entering directory 'C:/dev/sip-4.14.3/sipgen'
 makefile:29: warning: overriding recipe for target '.c.o'
 makefile:26: warning: ignoring old recipe for target '.c.o'
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o main.o main.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o transform.o
 transform.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o gencode.o
 gencode.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o extracts.o
 extracts.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o export.o
 export.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o heap.o heap.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o parser.o
 parser.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o lexer.o
 lexer.c
 g++ -mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import
 -Wl,-enable-runtime-pseudo-reloc -Wl,-subsystem,console -Wl,-s -o sip.exe
 main.o transform.o gencode.o extracts.o export.o heap.o parser.o lexer.o

 mingw32-make[1]: Leaving directory 'C:/dev/sip-4.14.3/sipgen'
 mingw32-make[1]: Entering directory 'C:/dev/sip-4.14.3/siplib'
 makefile:29: warning: overriding recipe for target '.c.o'
 makefile:26: warning: ignoring old recipe for target '.c.o'
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
 -IC:\Python27\include\python2.7 -o siplib.o siplib.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
 -IC:\Python27\include\python2.7 -o apiversions.o apiversions.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
 -IC:\Python27\include\python2.7 -o descriptors.o descriptors.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
 -IC:\Python27\include\python2.7 -o qtlib.o qtlib.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
 -IC:\Python27\include\python2.7 -o threads.o threads.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
 -IC:\Python27\include\python2.7 -o objmap.o objmap.c
 In file included from C:\Python27\include\python2.7/Python.h:58:0,
  from sip.h:32,
  from objmap.c:23:
 C:\Python27\include\python2.7/pyport.h:232:9: error: #error This platform's
 pyconfig.h needs to define PY_FORMAT_SIZE_T
 makefile:29: recipe for target 'objmap.o' failed
 mingw32-make[1]: *** [objmap.o] Error 1
 mingw32-make[1]: Leaving directory 'C:/dev/sip-4.14.3/siplib'
 makefile:3: recipe for target 'all' failed
 mingw32-make: *** [all] Error 2


 On Wed, Mar 13, 2013 at 2:33 PM, Ray Donnelly mingw.andr...@gmail.com
 wrote:

 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.

 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
  

Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers

2013-03-13 Thread NightStrike
On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen vinsc...@redhat.com wrote:
 Hi,

 I'd like to resurrect a patch which has been refused last year, but
 I think it's still helpful and maybe the opinions have changed a bit.

Sorry.. did I refuse it?  Can you link to the mailing list archive (I
understand that the SF interface blows for that...)

 For people building just the latest mingw64-headers and mingw64-crt,
 it's kind of surprising that mingw64-crt requires that the headers
 are already installed.  In theory, the right thing to do should be
 that mingw64-crt is build after mingw64-headers, and then prefer the
 just built in-tree headers over the already installed headers.

I'm a little confused here.  What we require, ie, the only situation
that we support, is when the version of the headers is the same
version of the crt.  Ie, svn checkout revision.  Anything outside of
that will probably work, of course, but nobody tests it.

Now, in terms of the configure test that errors out in the case of not
finding _mingw_mac.h, that is due to the fact that the headers are
required to build the crt.  We don't care where they are, we just care
that they exist.  If they don't, the crt build will be all fouled up.

The default, of course, is for the headers to exist in the sysroot
that the crt is getting installed into.  This is a fairly common usage
pattern, and modeled after the gcc build.  If they're somewhere else
instead, you can just use --with-sysroot=some/wheres/else

In fact, the help text for with-sysroot even says this:
 --with-sysroot=DIR   Search for headers within DIR/include

So if you for whatever reason want to stage a build of
mingw-w64-headers in /tmp/my/dir, you just build the crt with
--with-sysroot=/tmp/my/dir

Does that not work for you?




  The
 below patch does that, unless the --without-headers option is set.

 This should work in all typical scenarios:

 - cross build gcc:

   The headers have to be build first.  At the time crt gets build,
   the in-tree headers already have been built for gcc, so they
   are nicely available for the crt build.

 - native build gcc:

   The installed headers are potentially old.  Building crt with the
   latest in-tree headers is preferrable to circumnavigate potential
   bugs in the older headers.

 - native mingw-only build:

   Same as above.

 I can't come up with a scenario in which it would be bad to use the
 in-tree headers, unless you don't build the headers, but crt only.
 This should be fixable, shouldn't it?

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