Ben Sizer wrote:
In theory, yeah. In practice, if his compiler was somehow not
respecting that, then a quicker fix is to enclose the #include than to
do individual prototypes. Admittedly that might obscure the problem
rather than solve it.
Well, I'd say that the should in
You should put the
On Jul 23, 1:19 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Ben Sizer wrote:
> > You should put the extern block around the #include call
> > rather than individual functions, as surely the C calling convention
> > should apply to everything within.
>
> Hello? Python's include files are C++ sa
> 1>application.obj : error LNK2031: unable to generate p/invoke for
> "extern "C" void __clrcall Py_Exit(int)" (?Py_Exit@@[EMAIL PROTECTED]);
> calling convention missing in metadata
The main problem here is the __clrcall hint: apparently, you are
using Managed C++ resp. C++/CLI, i.e. the Microso
Jaco Naude wrote:
Fredrik, thanks for the help. I'm not sure why but it seems to work
now even if I don't include the extern "C" command. It also works with
both Python.h files (after I copied pyconfig.h from the PC folder). So
it seems like everything is working now.
As it's supposed to do.
On Jul 23, 2:08 pm, Ben Sizer <[EMAIL PROTECTED]> wrote:
> On Jul 23, 11:43 am, Jaco Naude <[EMAIL PROTECTED]> wrote:
>
> > What Visual C++ is doing is that it is looking for mangled names since
> > it does not know the DLL contains C functions. I've managed to work
> > around this by declaring the
Ben Sizer wrote:
You should put the extern block around the #include call
rather than individual functions, as surely the C calling convention
should apply to everything within.
Hello? Python's include files are C++ safe. I even posted a complete
compiler session to show that I'm not makin
On Jul 23, 11:43 am, Jaco Naude <[EMAIL PROTECTED]> wrote:
> What Visual C++ is doing is that it is looking for mangled names since
> it does not know the DLL contains C functions. I've managed to work
> around this by declaring the Python functions as follows before using
> them in the C++ applica
On Jul 23, 1:50 pm, Jaco Naude <[EMAIL PROTECTED]> wrote:
> On Jul 23, 1:10 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>
>
> > Jaco Naude wrote:
> > > What Visual C++ is doing is that it is looking for mangled names since
> > > it does not know the DLL contains C functions. I've managed to work
Jaco Naude wrote:
That said, let me double check something which might be causing
problems since you will be familiar with this. Which Python.h file do
you include when including the DLL in your programs? The one in the
source distribution of the one in the installation distribution? I've
been i
On Jul 23, 1:10 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Jaco Naude wrote:
> > What Visual C++ is doing is that it is looking for mangled names since
> > it does not know the DLL contains C functions. I've managed to work
> > around this by declaring the Python functions as follows before usi
Fredrik Lundh wrote:
> cl cl -EHsc -MD -I \python25\include test.cc \python25\libs\python25.lib
cut and paste error there: the "cl cl" should be just one "cl", of course.
and just for the record/google, if I
1) don't include the header file, I get
test.cc(5) : error C3861: 'Py_Initialize':
Jaco Naude wrote:
What Visual C++ is doing is that it is looking for mangled names since
it does not know the DLL contains C functions. I've managed to work
around this by declaring the Python functions as follows before using
them in the C++ application side:
extern "C"
{
void Py_Initializ
On Jul 23, 12:16 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Jaco Naude wrote:
> > good point. I agree that the problem is probably due to name mangling.
> > I'm not sure how its possible to tell the application that the DLL is
> > a C dll? I've looked at the DLL using Dependency Walker and the
Jaco Naude wrote:
good point. I agree that the problem is probably due to name mangling.
I'm not sure how its possible to tell the application that the DLL is
a C dll? I've looked at the DLL using Dependency Walker and the
functions in the DLL are clean (Thus no name mangling used).
>
How do I
On Jul 23, 9:59 am, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Jaco Naude wrote:
> > 1>application.obj : error LNK2031: unable to generate p/invoke for
> > "extern "C" void __clrcall Py_Exit(int)" (?Py_Exit@@[EMAIL PROTECTED]);
> > calling convention missing in metadata
> > 1>frmPythonInterface.obj
Jaco Naude wrote:
1>application.obj : error LNK2031: unable to generate p/invoke for
"extern "C" void __clrcall Py_Exit(int)" (?Py_Exit@@[EMAIL PROTECTED]);
calling convention missing in metadata
1>frmPythonInterface.obj : error LNK2031: unable to generate p/invoke
for "extern "C" void __clrcall
Hi there,
This is my first post over here and I hope someone can give me some
guidance.
I'm trying to embed Python into a Visual C++ 2008 application and I'm
getting linker problems. I've compiled a DLL of the Python source code
using the pythoncode VC++ project in the PCbuild folder of the sourc
17 matches
Mail list logo
