Mail Archives: cygwin/2000/11/08/15:27:04
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<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 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
- Raw text -