From: Saúl I. C. <sa...@ag...> - 2010-06-16 12:49:37
|
Hi all, It's my fist mail to this mailing list, I've been browsing the archives for a solution to my issue, but I'm unable to find it. If it has been answered before, please point me to the right place :) I'm porting a python application which has a C module built with Cython into Windows. The build process looks successful and I get the pyd file, but when I import it from Python I get the following error: $ python Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from sipsimple.core import Engine 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x71690000, RegionSize 0x410000, State 0x10000 c:\Python25\python.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 6 All I could find is somehow related to 'rebasing' something, but I'm not really familiar with what exactly 'rebase' means in the MinGW context and why should I need it. Moreover, everything runs for me in MinGW except for this (I've read that for some not even ls.exe was working). I'm running Windows XP SP3 with latest MSYS and MinGW packages manually installed. Any hint on how to debug this would be greatly appreciated :) Best regards, -- Saúl Ibarra Corretgé AG Projects |
From: Jason C. <jcu...@ar...> - 2010-06-16 17:07:04
|
Hello Saúl, On 16/06/2010 14:31, Saúl Ibarra Corretgé wrote: > Hi all, > > It's my fist mail to this mailing list, I've been browsing the archives > for a solution to my issue, but I'm unable to find it. If it has been > answered before, please point me to the right place :) > > I'm porting a python application which has a C module built with Cython > into Windows. The build process looks successful and I get the pyd file, > but when I import it from Python I get the following error: > > $ python > Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit > (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> from sipsimple.core import Engine > 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 > error 487 > AllocationBase 0x0, BaseAddress 0x71690000, RegionSize 0x410000, State > 0x10000 > c:\Python25\python.exe: *** Couldn't reserve space for cygwin's heap, > Win32 error 6 > I'm not sure if this is supported - I know a little that Cygwin allocates 4k of stack at the base of a process when it starts. You might want to ask the Cygwin list for help. But for them to help, you must be clear about what is Cygwin and what is MinGW. The two are *very* different from run-times. For example, I can't tell if your Python is for Cygwin or MinGW, or if you compiled the extension for Cygwin or MinGW. But one thing for sure, your error is Cygwin related, probably because it wasn't initialised properly, probably because you're mixing the two (and you shouldn't). > All I could find is somehow related to 'rebasing' something, but I'm not > really familiar with what exactly 'rebase' means in the MinGW context > and why should I need it. Moreover, everything runs for me in MinGW > except for this (I've read that for some not even ls.exe was working). > > I'm running Windows XP SP3 with latest MSYS and MinGW packages manually > installed. > > Any hint on how to debug this would be greatly appreciated :) > My first suggestion is to make sure you're using the correct compilers. Regards. Jason. |
From: Saúl I. C. <sa...@ag...> - 2010-06-16 18:05:01
|
Hi Jason, Thanks for your answer! > I'm not sure if this is supported - I know a little that Cygwin > allocates 4k of stack at the base of a process when it starts. > > You might want to ask the Cygwin list for help. But for them to help, > you must be clear about what is Cygwin and what is MinGW. The two are > *very* different from run-times. For example, I can't tell if your > Python is for Cygwin or MinGW, or if you compiled the extension for > Cygwin or MinGW. But one thing for sure, your error is Cygwin related, > probably because it wasn't initialised properly, probably because you're > mixing the two (and you shouldn't). I haven't installed cygwin at all, I just installed MSYS and MinGW, and I got Python as a MSI from the official website, so (correct me if I'm wrong) I'm not using cygwin, right? > My first suggestion is to make sure you're using the correct compilers. > I downloaded all packages from MinGW sourceforge project and I'm able to compile simple Python extensions (hello world and such) but this one contains a whole C library statically linked, and I don't know where to begin debugging :-S Regards, -- Saúl Ibarra Corretgé AG Projects |
From: JonY <jo...@us...> - 2010-06-17 03:18:52
|
On 6/17/2010 02:04, Saúl Ibarra Corretgé wrote: > Hi Jason, > > Thanks for your answer! > >> I'm not sure if this is supported - I know a little that Cygwin >> allocates 4k of stack at the base of a process when it starts. >> >> You might want to ask the Cygwin list for help. But for them to help, >> you must be clear about what is Cygwin and what is MinGW. The two are >> *very* different from run-times. For example, I can't tell if your >> Python is for Cygwin or MinGW, or if you compiled the extension for >> Cygwin or MinGW. But one thing for sure, your error is Cygwin related, >> probably because it wasn't initialised properly, probably because you're >> mixing the two (and you shouldn't). > > I haven't installed cygwin at all, I just installed MSYS and MinGW, and > I got Python as a MSI from the official website, so (correct me if I'm > wrong) I'm not using cygwin, right? > MSYS is based on Cygwin 1.3, so its still considered Cygwin enough. |
From: Saúl I. C. <sa...@ag...> - 2010-06-17 07:37:58
|
>> I haven't installed cygwin at all, I just installed MSYS and MinGW, and >> I got Python as a MSI from the official website, so (correct me if I'm >> wrong) I'm not using cygwin, right? >> > > MSYS is based on Cygwin 1.3, so its still considered Cygwin enough. Humm, I didn't know that :-S I've read about it now, so the fact that I read 'cygwin' while I didn't explicitly installed makes sense now :) Now, any ideas on how to debug this? I tried gdb, but I won't get any backtrace :-S Any other clue? Thanks you very much for clarifying things :) Regards, -- Saúl Ibarra Corretgé AG Projects |
From: JonY <jo...@us...> - 2010-06-17 08:03:14
|
On 6/17/2010 15:37, Saúl Ibarra Corretgé wrote: > >>> I haven't installed cygwin at all, I just installed MSYS and MinGW, and >>> I got Python as a MSI from the official website, so (correct me if I'm >>> wrong) I'm not using cygwin, right? >>> >> >> MSYS is based on Cygwin 1.3, so its still considered Cygwin enough. > > Humm, I didn't know that :-S > > I've read about it now, so the fact that I read 'cygwin' while I didn't > explicitly installed makes sense now :) > > Now, any ideas on how to debug this? I tried gdb, but I won't get any > backtrace :-S > > Any other clue? > Hi, how was the python module built anyway? Did you build it with GCC? Does it have any dependencies? |
From: Saúl I. C. <sa...@ag...> - 2010-06-17 08:37:34
|
Hi JoY, > how was the python module built anyway? Did you build it with GCC? Does > it have any dependencies? It's a Cython extension statically linked against another library. The result is one big 'core.pyd' file with everything inside it. I made a simple Cython test which printed some numbers and that worked, so I guess this whole library linking stuff is the one to blame, but I can't see where to start debugging :-S This how the module extension is being built: building 'sipsimple.core._core' extension c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DPJ_AUTOCONF=1 -DPJ_SVN_REVISION=2830 -Ic:/msys/1.0/include -Ic:/work/p ython-sipsimple/build/temp.win32-2.6/Release/pjsip/pjlib/include -Ic:/work/python-sipsimple/build/temp.win32-2.6/Release /pjsip/pjlib-util/include -Ic:/work/python-sipsimple/build/temp.win32-2.6/Release/pjsip/pjnath/include -Ic:/work/python- sipsimple/build/temp.win32-2.6/Release/pjsip/pjmedia/include -Ic:/work/python-sipsimple/build/temp.win32-2.6/Release/pjs ip/pjsip/include -Ic:\Python26\include -Ic:\Python26\PC -c sipsimple/core\_core.c -o build\temp.win32-2.6\Release\sipsim ple\core\_core.o -Wno-unused-variable writing build\temp.win32-2.6\Release\sipsimple\core\_core.def c:\mingw\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.6\Release\sipsimple\core\_core.o build\temp.win32-2.6\Rel ease\sipsimple\core\_core.def -Lc:/work/python-sipsimple/build/temp.win32-2.6/Release/pjsip/pjlib/lib -Lc:/work/python-s ipsimple/build/temp.win32-2.6/Release/pjsip/pjlib-util/lib -Lc:/work/python-sipsimple/build/temp.win32-2.6/Release/pjsip /pjnath/lib -Lc:/work/python-sipsimple/build/temp.win32-2.6/Release/pjsip/pjmedia/lib -Lc:/work/python-sipsimple/build/t emp.win32-2.6/Release/pjsip/pjsip/lib -Lc:/work/python-sipsimple/build/temp.win32-2.6/Release/pjsip/third_party/lib -Lc: /msys/1.0/lib -Lc:\Python26\libs -Lc:\Python26\PCbuild -lpjsip-ua-i686-pc-mingw32 -lpjsip-simple-i686-pc-mingw32 -lpjsip -i686-pc-mingw32 -lpjmedia-codec-i686-pc-mingw32 -lpjmedia-i686-pc-mingw32 -lpjnath-i686-pc-mingw32 -lpjlib-util-i686-pc -mingw32 -lresample-i686-pc-mingw32 -lmilenage-i686-pc-mingw32 -lsrtp-i686-pc-mingw32 -lgsmcodec-i686-pc-mingw32 -lspeex -i686-pc-mingw32 -lilbccodec-i686-pc-mingw32 -lportaudio-i686-pc-mingw32 -lpj-i686-pc-mingw32 -lm -lwinmm -lole32 -lws2_ 32 -lwsock32 -lpthread -lssl -lcrypto -lpython26 -lmsvcr90 -o c:\work\python-sipsimple\sipsimple\core\_core.pyd Besides from the custom libraries being linked, do you see anything weird there? Thanks and regards, -- Saúl Ibarra Corretgé AG Projects |
From: JonY <jo...@us...> - 2010-06-17 14:01:48
|
On 6/17/2010 16:37, Saúl Ibarra Corretgé wrote: > Hi JoY, > >> how was the python module built anyway? Did you build it with GCC? Does >> it have any dependencies? > > It's a Cython extension statically linked against another library. The > result is one big 'core.pyd' file with everything inside it. > > I made a simple Cython test which printed some numbers and that worked, > so I guess this whole library linking stuff is the one to blame, but I > can't see where to start debugging :-S > > This how the module extension is being built: > > building 'sipsimple.core._core' extension > c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DPJ_AUTOCONF=1 > -DPJ_SVN_REVISION=2830 -Ic:/msys/1.0/include -Ic:/work/p > ython-sipsimple/build/temp.win32-2.6/Release/pjsip/pjlib/include > -Ic:/work/python-sipsimple/build/temp.win32-2.6/Release > /pjsip/pjlib-util/include > -Ic:/work/python-sipsimple/build/temp.win32-2.6/Release/pjsip/pjnath/include > -Ic:/work/python- > sipsimple/build/temp.win32-2.6/Release/pjsip/pjmedia/include > -Ic:/work/python-sipsimple/build/temp.win32-2.6/Release/pjs > ip/pjsip/include -Ic:\Python26\include -Ic:\Python26\PC -c > sipsimple/core\_core.c -o build\temp.win32-2.6\Release\sipsim > ple\core\_core.o -Wno-unused-variable > > writing build\temp.win32-2.6\Release\sipsimple\core\_core.def > c:\mingw\bin\gcc.exe -mno-cygwin -shared -s > build\temp.win32-2.6\Release\sipsimple\core\_core.o > build\temp.win32-2.6\Rel > ease\sipsimple\core\_core.def > -Lc:/work/python-sipsimple/build/temp.win32-2.6/Release/pjsip/pjlib/lib > -Lc:/work/python-s > ipsimple/build/temp.win32-2.6/Release/pjsip/pjlib-util/lib > -Lc:/work/python-sipsimple/build/temp.win32-2.6/Release/pjsip > /pjnath/lib > -Lc:/work/python-sipsimple/build/temp.win32-2.6/Release/pjsip/pjmedia/lib -Lc:/work/python-sipsimple/build/t > > emp.win32-2.6/Release/pjsip/pjsip/lib > -Lc:/work/python-sipsimple/build/temp.win32-2.6/Release/pjsip/third_party/lib > -Lc: > /msys/1.0/lib -Lc:\Python26\libs -Lc:\Python26\PCbuild > -lpjsip-ua-i686-pc-mingw32 -lpjsip-simple-i686-pc-mingw32 -lpjsip > -i686-pc-mingw32 -lpjmedia-codec-i686-pc-mingw32 > -lpjmedia-i686-pc-mingw32 -lpjnath-i686-pc-mingw32 -lpjlib-util-i686-pc > -mingw32 -lresample-i686-pc-mingw32 -lmilenage-i686-pc-mingw32 > -lsrtp-i686-pc-mingw32 -lgsmcodec-i686-pc-mingw32 -lspeex > -i686-pc-mingw32 -lilbccodec-i686-pc-mingw32 -lportaudio-i686-pc-mingw32 > -lpj-i686-pc-mingw32 -lm -lwinmm -lole32 -lws2_ > 32 -lwsock32 -lpthread -lssl -lcrypto -lpython26 -lmsvcr90 -o > c:\work\python-sipsimple\sipsimple\core\_core.pyd > > Besides from the custom libraries being linked, do you see anything > weird there? > No, I don't see anything that directly links to cygwin. Try tracking which dlls are loaded at runtime, especially during module loading. |
From: Martin P. <pru...@gm...> - 2010-06-18 03:09:18
|
On Thu, Jun 17, 2010 at 5:37 AM, Saúl Ibarra Corretgé <sa...@ag...> wrote: > building 'sipsimple.core._core' extension > c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DPJ_AUTOCONF=1 > -DPJ_SVN_REVISION=2830 -Ic:/msys/1.0/include -Ic:/work/p ... Guess "-Ic:/msys/1.0/include" can be the source of your problem... > writing build\temp.win32-2.6\Release\sipsimple\core\_core.def > c:\mingw\bin\gcc.exe -mno-cygwin -shared -s ... > -Lc: > /msys/1.0/lib -Lc:\Python26\libs -Lc:\Python26\PCbuild ... And "-Lc:/msys/1.0/lib", it looks like you link with something from msys. Try cutting these lines to see the errors then go after non-msys-dependent alternatives. Prusse |
From: Keith M. <kei...@us...> - 2010-06-18 21:02:08
|
On Friday 18 June 2010 04:09:09 Martin Prüsse wrote: > On Thu, Jun 17, 2010 at 5:37 AM, Saúl Ibarra Corretgé > > <sa...@ag...> wrote: > > building 'sipsimple.core._core' extension > > c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DPJ_AUTOCONF=1 > > -DPJ_SVN_REVISION=2830 -Ic:/msys/1.0/include -Ic:/work/p > > ... > > Guess "-Ic:/msys/1.0/include" can be the source of your problem... Good spot. This is almost certain to be a major contributing factor. > > writing build\temp.win32-2.6\Release\sipsimple\core\_core.def > > c:\mingw\bin\gcc.exe -mno-cygwin -shared -s > > ... > > > -Lc: > > /msys/1.0/lib -Lc:\Python26\libs -Lc:\Python26\PCbuild > > ... > > And "-Lc:/msys/1.0/lib", it looks like you link with something from > msys. Exactly so. Furthermore, what's the -mno-cygwin nonsense supposed to achieve? That's a nasty, and now deprecated kludge for cygwin, to use the mingw32 compiler, without properly setting up a cross-tool chain; AFAIK, the cygwin folks have now seen the light, and do this properly, but in any case, that option is a no-op for MinGW GCC. Anyway, the primary point here is that you are using -mno-cygwin in a forlorn attempt to avoid cygwin dependencies, yet you are then explicitly trying to add those same dependencies back by specifying MSYS runtime (i.e. forked cygwin) libraries to the linker. You can't do that; either you are building an MSYS/cygwin app, in which case you *must* use the MSYS or cygwin GCC (without the -mno-cygwin flag), or you are building a MinGW app, (which you seem to be trying to do because you are using the MinGW GCC). There is no half-way house. A MinGW app cannot use MSYS or cygwin libraries; it will never work. > Try cutting these lines to see the errors then go after > non-msys-dependent alternatives. Or else go build as a cygwin app from the outset. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-06-18 23:50:13
|
On 6/18/2010 7:30 AM, Keith Marshall wrote: > Exactly so. Furthermore, what's the -mno-cygwin nonsense supposed to > achieve? That's a nasty, and now deprecated kludge for cygwin, to > use the mingw32 compiler, without properly setting up a cross-tool > chain; AFAIK, the cygwin folks have now seen the light, and do this > properly, but in any case, that option is a no-op for MinGW GCC. Well, the cygwin folks would LIKE to do this properly, but they still have not provided a pre-compiled cygwin-packaged cygwin-to-mingw compiler toolchain. Supposedly one is coming Real Soon Now(tm)... In the meantime, "they" still have to use their gcc-3.4.5 toolchain, which still supports -mno-cygwin... It's a non-optimal situation. -- Chuck |
From: Saúl I. C. <sa...@ag...> - 2010-06-19 13:53:37
|
Hi, First, thanks for your really helpful answers. >> Guess "-Ic:/msys/1.0/include" can be the source of your problem... > > Good spot. This is almost certain to be a major contributing factor. > >>> writing build\temp.win32-2.6\Release\sipsimple\core\_core.def >>> c:\mingw\bin\gcc.exe -mno-cygwin -shared -s >> >> ... >> >>> -Lc: >>> /msys/1.0/lib -Lc:\Python26\libs -Lc:\Python26\PCbuild >> >> ... >> >> And "-Lc:/msys/1.0/lib", it looks like you link with something from >> msys. > I specifically added those paths in order to use MSYS OpenSSL. I'll install the standalone version and remove the dependency. If I understood correctly, the idea her would be *not* to make the Python extension depend on MSYS at all. So I guess that every library I might be missing should be compiled by hand with MinGW in order to avoid the MSYS dependency, right? > Exactly so. Furthermore, what's the -mno-cygwin nonsense supposed to > achieve? That's a nasty, and now deprecated kludge for cygwin, to > use the mingw32 compiler, without properly setting up a cross-tool > chain; AFAIK, the cygwin folks have now seen the light, and do this > properly, but in any case, that option is a no-op for MinGW GCC. > > Anyway, the primary point here is that you are using -mno-cygwin in a > forlorn attempt to avoid cygwin dependencies, yet you are then > explicitly trying to add those same dependencies back by specifying > MSYS runtime (i.e. forked cygwin) libraries to the linker. You can't > do that; either you are building an MSYS/cygwin app, in which case > you *must* use the MSYS or cygwin GCC (without the -mno-cygwin flag), > or you are building a MinGW app, (which you seem to be trying to do > because you are using the MinGW GCC). There is no half-way house. A > MinGW app cannot use MSYS or cygwin libraries; it will never work. > I didn't know anything about this, thanks for the pointer. I'm using the -c mingw32 modifier when building the Python extension, so I guess that's the reason for the -nmo-cygwin to be added (I didn't do it explicitly). I'll remove the MSYS dependencies and try again. Kind regards, -- Saúl Ibarra Corretgé AG Projects |
From: Saúl I. C. <sa...@ag...> - 2010-06-21 08:18:10
|
Hi, > I'll remove the MSYS dependencies and try again. > To answer myself, that did work! :) I removed the MSYS related dependencies (which I only used for OpenSSL) and replaced them with the dependency on the standalone OpenSSL package. Thank you *very* much for the help provided. Kind regards, -- Saúl Ibarra Corretgé AG Projects |