This is I guess a question in a few parts.
I’m working through the documentation on embedding the python interpreter. I’ve got everything compiling and linking wonderfully, only the application crashes when I run it ( to be specific its unable to load, so it hasn’t even begun running).
I’m running windows 7 professional 64 bit. I’m compiling on the most recent nightly build of mingw, with msys ( which was packaged with the installer so no compatibility mismatch there I believe). The same code compiles fine on Ubuntu 10.10 using the default repository python 3.1 and build-essential tools.
So far in my research I’m believing this “might” be an issue between linking a 32 bit application ( as mingw is using 32 bit to my knowledge) with a 64 bit library (the python dll).
I can post code in full, however since this tends to be a linking/running issue I’ve only included the makefile to begin with. From the makefile below, I have copied the Python3.dll from C:\Python32\DLLs into the directory of my project. Also of note, that I had to create my own .def and then .a from the DLL in order to link ( symbols not found otherwise). Could this be a source of my issues?
Upon running a.exe (from both command line and explorer) I receive a standard alert window with:
Application Error: The application was unable to start correctly (0xc000007b). Click OK to close the application.
Correct me if I’m wrong, but this indicates that my executable is in some way corrupted.
I have tested my compiler/linker to ensure that it isn’t a compiler/linker issue. It includes and this does NOT throw any errors on compiling, linking or running when the application does not use python.
Thanks for any assistance or light you can shed on the matter. This has me truly stumped.
pcnerd
Makefile
FILE= main.cpp
LIBS= -lpython3
LIBPATH= -L/c/python32/libs
INCLUDEPATH = -I/c/python32/include
CPP=g++
FLAGS = -g
build:
$(CPP) $(FLAGS) $(FILE) $(LIBS) $(LIBPATH) $(INCLUDEPATH)
If the python3.dll is definitely 64bit and your application is definitely 32bit, then this will not work. You can’t link to 64bit dlls from 32bit applications. Pointers just won’t be able to work between the two models.