Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Wed, 8 Nov 2000 15:16:08 -0500 From: Jason Tishler To: Mitsuo Igarashi Cc: cygwin AT sources DOT redhat DOT com Subject: Re: How to make an extension of Python Message-ID: <20001108151608.A324@dothill.com> References: <000801c04891$d8b25ec0$12f0fea9 AT mitsu5> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000801c04891$d8b25ec0$12f0fea9@mitsu5>; from mitsu5@ruby.famille.ne.jp on Tue, Nov 07, 2000 at 05:07:54PM +0900 Organization: Dot Hill Systems Corp. 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 AT 12 --target=i386-mingw32 -L \ > >-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 DOT Tishler AT dothill DOT com Hazlet, NJ 07730 USA WWW: http://www.dothill.com -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com