How to make an extension of Python
Wed Nov 8 12:16:00 GMT 2000
On Tue, Nov 07, 2000 at 05:07:54PM +0900, Mitsuo Igarashi wrote:
> Wonderful !!!
> This method is completely successful in my enviroment.
I'm glad that my patch works for you too. You're number 3 including
> I have tried another usual build up of python2.0 without your patch and make
> the extension of xx.dll by the make_shared method. Then I get an error
> message when importing xx.dll: "Fatal Python error: Interpreter not
> May I have questions?
> Question 1).
> Why does the usual build up of python end in a failure in making an
Because the usual Cygwin Python build does not produce the import
library needed by extensions and even if it did python.exe does not
export those symbols anyway.
> What is your patch doing to correct the failure?
The key to my patch is that it builds the Python core as a DLL just
like the Win32 version does. Once Python is built as a "shared library"
(i.e., DLL), developers can build extensions just like on any other UNIX
platform that supports shared libraries.
Actually building Python as a DLL was much easier than I thought --
mainly because the same code already compiles as a DLL on Win32. The hard
part was integrating into the idiosyncrasies of Python's autoconf, make,
and makesetup build infrastructure.
I believe that one could have alternatively modified the build procedure
to produce the import library and export those symbols directly from
python.exe without building a DLL. This is similar to what PostgreSQL
does for postgres.exe and pgpsql.dll. I decided against this approach
for three reasons:
1. I feel that consistency between the Win32 and Cygwin versions is
2. The DLL approach is better for embedded Python too.
3. I already had the DLL approach working and didn't want to start
all over again.
Obviously, reason #3 above is the most compelling. :,)
> In another mail on "RE: How to make an extension of Python", Anthony
> Tuininga tells
> >I do not use anything from DLL helpers but rather simply use dllwrap
> (version 0.2.4) with> the following command (NOT UNDER CYGWIN, btw); P.S.
> Note that double dashes which were m>issing in your post (may be a typing
> error but just in case.... :-)
Who's post? Anthony's or mine?
> >dllwrap --def cx_Oracle.def --output-lib libcx_Oracle.a --dllname
> cx_Oracle.dll \
> > cx_Oracle.o -L/Tools/Library/Win32 -loci -lpython20
> I tried the following written procedure that ended up in the error message:
> dllwrap -o myEnviron.pyd -def myEnviron.def myEnviron.o -lpython2.0
> "Importerror: dynamic modules does not define init
> function ( initmyEnviron)".
My guess is for some reason initmyEnviron is not being exported from
myEnviron.pyd. What is the contents of your myEnviron.def file?
> I could create the extension of "environ.c" according to the following
> instruction by Mingw32.
> Instructions for Python Extensions with GCC/mingw32 by Robert Kern.
> >dllwrap --dllname foo.pyd --driver-name gcc --def foo.def -o foo.pyd \
> >foomodule.o -s --entry _DllMain@12 --target=i386-mingw32 -L<py-lib-dir> \
> However, the same "environ.c" could not be a successful dll binary in
Were you importing the above module into the Win32 or Cygwin Python?
> Question 2)
> Why did the simple dllwrap smoetimes successfully create an extension
> and another time unsuccessfully in Cygwin?
Sorry, I don't know the answer to the above.
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org
More information about the Cygwin