Py_Initialize() fails on windows when SDL.h is included.
I began porting one of my projects from linux (no problems under
linux) to windows, but I am getting the following problem when
attempting to run it (This was within gdb)
warning: Fatal Python error:
warning: Py_Initialize: can't initialize sys standard streams
warning:
I narrowed it down the following testcase,
#include
#include
int main(int argc, char*argv[])
{
Py_Initialize();
}
commenting out the first include (SDL/SDL.h) allows it to run w/o any problems.
SDL-1.2.13, Python 3.1.3 (Also tested w/ 3.2.), GCC 4.5.1,
w32api-3.17.1, mingw-rt-3.18 (Toolchain is a linux to windows cross
compiler, designed from
http://nathancoulson.com/proj_cross_mingw.shtml)
I noticed when I mess with the include order (Python.h before SDL.h), it gives
3rdparty/i686-pc-mingw32/include/SDL/SDL_config.h:131:0: warning:
"HAVE_SNPRINTF" redefined
3rdparty/i686-pc-mingw32/include/python3.2/pyerrors.h:361:0: note:
this is the location of the previous definition
it is defined in SDL_config.h as
#define HAVE_SNPRINTF 1
although no clue if it's related... probably a red herring
--
Nathan Coulson (conathan)
--
Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Py_Initialize() fails on windows when SDL.h is included.
Recompiling SDL, using --disable-stdio-redirect fixed this problem.
On Tue, Mar 15, 2011 at 1:48 AM, Nathan Coulson wrote:
> I began porting one of my projects from linux (no problems under
> linux) to windows, but I am getting the following problem when
> attempting to run it (This was within gdb)
>
> warning: Fatal Python error:
> warning: Py_Initialize: can't initialize sys standard streams
> warning:
>
>
> I narrowed it down the following testcase,
>
> #include
> #include
>
> int main(int argc, char*argv[])
> {
> Py_Initialize();
> }
>
> commenting out the first include (SDL/SDL.h) allows it to run w/o any
> problems.
>
> SDL-1.2.13, Python 3.1.3 (Also tested w/ 3.2.), GCC 4.5.1,
> w32api-3.17.1, mingw-rt-3.18 (Toolchain is a linux to windows cross
> compiler, designed from
> http://nathancoulson.com/proj_cross_mingw.shtml)
>
> I noticed when I mess with the include order (Python.h before SDL.h), it gives
>
> 3rdparty/i686-pc-mingw32/include/SDL/SDL_config.h:131:0: warning:
> "HAVE_SNPRINTF" redefined
> 3rdparty/i686-pc-mingw32/include/python3.2/pyerrors.h:361:0: note:
> this is the location of the previous definition
>
> it is defined in SDL_config.h as
> #define HAVE_SNPRINTF 1
>
> although no clue if it's related... probably a red herring
>
> --
> Nathan Coulson (conathan)
> --
> Location: British Columbia, Canada
> Timezone: PST (-8)
> Webpage: http://www.nathancoulson.com
>
--
Nathan Coulson (conathan)
--
Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com
--
http://mail.python.org/mailman/listinfo/python-list
Looking for ideas on controlling python module loading
Hello, I am working on a client/server program (game) that uses C w/ an embedded python interpreter, that uses python to script what objects do in the game. (primarily a C environment) I was wondering if it is possible to control what modules get loaded (or not). perhaps by determining if the hash of the local file matches a hash provided by the server. I was also wondering, if you could construct a module, without a .py file, and define functions and variables. -- Nathan Coulson (conathan) -- Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://mail.python.org/mailman/listinfo/python-list
looking for libpython31.a 64bit (missing from python-3.1.3.amd64.msi)
Well, as the subject says, I am looking to find libpython31.a [win64bit version] for use in a linux to windows 64bit cross compiler [x86_64-w64-mingw32-gcc], but seems to be missing. so far, tried installing it on a real 64bit windows system, cabextract, as well as msiexec /a python-3.1.3.amd64.msi /qb TARGETDIR=out. Either case, libs/libpython31.a is not there. as a last resort, tried cross compiling it with my tools, but a few google searches tell me that way will lead to headaches, and currently not supported out of the box. -- Nathan Coulson (conathan) -- Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://mail.python.org/mailman/listinfo/python-list
Re: looking for libpython31.a 64bit (missing from python-3.1.3.amd64.msi)
On Wed, Apr 13, 2011 at 7:03 PM, David Cournapeau wrote: > On Wed, Apr 13, 2011 at 5:17 PM, Nathan Coulson wrote: >> Well, as the subject says, I am looking to find libpython31.a >> [win64bit version] for use in a linux to windows 64bit cross compiler >> [x86_64-w64-mingw32-gcc], but seems to be missing. >> >> so far, tried installing it on a real 64bit windows system, >> cabextract, as well as msiexec /a python-3.1.3.amd64.msi /qb >> TARGETDIR=out. Either case, libs/libpython31.a is not there. >> >> as a last resort, tried cross compiling it with my tools, but a few >> google searches tell me that way will lead to headaches, and currently >> not supported out of the box. > > If you are willing to jump through a few oops. I have documented what > I needed last time I tried mingw-w64 for numpy: > > http://projects.scipy.org/numpy/wiki/MicrosoftToolchainSupport > > If anything, it should be easier now because mingw-w64 is much more > stable can can be installed without being compiled first (I wrote > those notes almost 2 years ago IIRC), > > cheers, > > David actually figured out a neat trick, mingw-w64 can link directly to the .dll. gcc file.c python31.dll -o file.exe no .a needed. http://www.mingw.org/wiki/sampleDLL (have yet to find out if it actually works yet, but so far looks promising) -- Nathan Coulson (conathan) -- Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://mail.python.org/mailman/listinfo/python-list
Re: looking for libpython31.a 64bit (missing from python-3.1.3.amd64.msi)
On Wed, Apr 13, 2011 at 7:53 PM, David Cournapeau wrote: > On Thu, Apr 14, 2011 at 11:28 AM, Nathan Coulson wrote: > >> actually figured out a neat trick, mingw-w64 can link directly to the .dll. >> gcc file.c python31.dll -o file.exe >> >> no .a needed. >> >> http://www.mingw.org/wiki/sampleDLL >> >> (have yet to find out if it actually works yet, but so far looks promising) > > Note the "If this method works for your application then there is > usually no need for an import library.". Whether it works or not is > often found the hard way (i.e. you won't have a linking error, but > subtle bugs). Building a .a library is more stable in my experience > (even in 32 bits). > > In any case, note the -DMS_WIN64 which is mandatory if you want to > make it work (without this define, mingw will use the python headers > for 32 bits, with pointers typedef defined for 32 bits pointers > instead of 64 bits, which will not work very well :) ). > > cheers, > > David very good note, had no clue. -- Nathan Coulson (conathan) -- Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://mail.python.org/mailman/listinfo/python-list
