Re: How to make an extension of Python

[Jason Tishler <Jason dot Tishler at dothill dot com>]

Mitsuo,

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
myself.

> 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
> initialized".
> 
> May I have questions?
> 
> Question 1).
>   Why does the usual build up of python end in a failure in making an
> extension?

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
       important.
    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.
> 
> http://starship.python.net/crew/kernr/mingw32/Notes.html
> 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> \
> >-lpython15
> However, the same "environ.c" could not be a successful dll binary in
> Cygwin.

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.

Jason

-- 
Jason Tishler
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 cygwin-unsubscribe@sourceware.cygnus.com