extending python with a C-written dll

[Jean-Baptiste PERIN]

Steve Holden a écrit :

I know it has nothing to do with python ..
It just makes me sad to see that python cannot get rid of Visual
Studoi to be extended . It's just amazing !!

Python is free
The compiler I use is free
The code I plan to produce will be free

Where can I find a free version of Visual Studio ?

the only thing I use that is not free is the operating system and it's
because I had no choice .. my company decided for it




Yes .. that's what I'm going to do .. but I find it frustrating ..

Perhaps you aren't aware that Microsoft make a free tool chain available
that can be used to create binary extensions? There has been some
discussion of this recently, and I managed to compile MySQLdb and a
couple of the mx extensions, so it's eminently doable [the PIL is
proving a little less tractable due to dependencies on other libraries
that I have yet to resolve].

The downloads are quite large, but if you want to try it, take a look at

http://www.vrplumber.com/programming/mstoolkit/

regards
Steve

If nothing else works .. I'll try that way ..
So far, I've tried to keep as far as possible from MS things ..

thank you for your help ...

 

[Jean-Baptiste PERIN]

Jean Brouwers a écrit :

First, you might check the calldll module available here

<http://www.nightmare.com/software.html>

I have one or two things to try before ..but it looks interesting ..
thank you very much ..

Take a look at Pyrex, it may fit your requirements to access C from
Python.

<http://nz.cosc.canterbury.ac.nz/~greg/python/Pyrex/>

Yes, pirex looks very powerful ..I heard about it already .. I know
someone who used it .. and the result was just amazing ..
there's also SWIG which looks very sexy
http://www.swig.org/tutorial.html

My current problem is a compilation one .. I need to first solve it
before exploring these tools ..

If you do not have these already, you may need the Win32 API extension

<http://www.python.org/windows/win32/>


/Jean Brouwers

Thank you very much Jean

 

[Jean-Baptiste PERIN]

Note that MinGW32 is a tested path for building (free) C extensions. I
don't know if anyone has a tested way of using lcc.

Yes, very interesting
I can already conclude that either I don't know how to use lcc
or it doesn't suit my needs ..
in both case I have to quickly get rid of it .. before I throw the
computer through the window ..

I plan to first test the cygwin's gcc compiler before goign to MinGW32

With MinGW32, your build step will be the delightfully easy:

python setup.py build --compiler=mingw32

Thank you very much for your help

 

[Jean-Baptiste PERIN]

John Machin a écrit :

Hi,

I'm trying to make a windows dll reachable from a python script ..
and

I'm encountering troubles during link step ..

I use "lcc" to compile and link
I use python 2.3 under win XP
[snip]

Here are the errors :
---------------------
Error c:\...\plugins\hello.c 14 undefined reference to
__imp__Py_BuildValue

Error c:\...\plugins\hello.c 46 undefined reference to
__imp__Py_InitModule4
[snip]

return Py_BuildValue("i", 1);
[snip]

void __declspec(dllexport) inithello()
{
(void)Py_InitModule3("hello", helloMethods, MHello__doc__);
Can anyone help me?

Yes. Option 1: *Maybe* you can help yourself. Have you not noticed from
the above that the compiler is magically prepending "__imp__" to the
names of external functions? However the .lib that comes with Python
won't have that "__imp__". You would have to bridge that gap, somehow.
Have you searched the lcc documentation? Are you prepared for the next
several problems that may arise?

Indeed, it's something I can't understand (the __imp__ stuff)..
Nothing appear about that in the
I have posted a question on lcc forum .. the author of lcc answered

"This happens because somewhere you are declaring the functions
Py_BuildValue
and
Py_InitModule

as __declspec(dllimport) "

He's right !!
He adviced me to change that ..
I don't want to make changes to python code .. so .. bye bye lcc

long life to gcc

By the way, lcc also *appears* to change "...Module3" to "...Module4"

this one is explainable to me .. it is due to the fact that both
function are equivalent

in mod support.h:

#define Py_InitModule3(name, methods, doc) \
Py_InitModule4(name, methods, doc, (PyObject *)NULL, \
PYTHON_API_VERSION)

Option 2: You have been helped already. There are two free compilers
which work quite well for developing extensions in C for win32
platforms; start reading here:

http://docs.python.org/inst/tweak-flags.html#SECTION000620000000000000000

I'm currently attracted by the cygwin solution .. that I find very sexy !!
If I fail .. I will explore the MingW ..

Thank you very much for helping me ..

 

[Scott David Daniels]

I can already conclude that either I don't know how to use lcc
or it doesn't suit my needs ..
I plan to first test the cygwin's gcc compiler before goign to MinGW32

MinGW32 is "Minimalist Gnu for Windows -- 32-bit," and _works_ at
being ABI compatible with Microsoft's ABI and its C runtime. Cygwin
is a way of building a *nix-compatible toolset _on_ Windows, not _in_
windows. What that means (as far as I understand the issues) is that
you'll need to build a Cygwin python in order to use Cygwin modules.
I put in a bit of effort to make sure Python could build for that
compiler (not by MinGW-specific code, but by cleaning up an issue in
the CPython header file for non-MS compilers). There are toolchain
issues to consider (not just the compiler itself, , but function call
conventions, global access, linker/loader, and debugger symbols and
access are involved).

Python 2.4's jump to a new C compiler on windows is a well-justified
decision (Windows C/C++ 6.0's stuff is getting long in the tooth), but
short-term disruptive to small-time Python C module development. The
change does not portend a continuous series of compiler-jumps, but
rather a hope to not become hopelessly mired in ancient history. It
is getting hard (or is impossible, I don't know which) to purchase
Windows C/C++ 6.0 for money these days, and this will only get harder.

In short, I urge you to go with MinGW if you are hoping to write for
windows with a GNU compiler; you'll be swimming upstream a bit less.

--Scott David Daniels
(e-mail address removed)