Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Message-ID:	<000b01c04ae9$21360e40$f06afea9@mitsu5>
From:	"Mitsuo Igarashi" <mitsu5 AT ruby DOT famille DOT ne DOT jp>
To:	<cygwin AT sources DOT redhat DOT com>
Subject:	RE: How to make an extension of Python
Date:	Fri, 10 Nov 2000 16:37:09 +0900
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 4.72.3110.5
X-MimeOLE:	Produced By Microsoft MimeOLE V4.72.3110.3

Jason

|> 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. :,)


Thanks lots for your kind explanation.

|> >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?


EXPORTS
 initenviron

|> 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?


cygwin python

This failure is probably the bad -lpython2.0.
"libpython2.0.a" is not shared?

Your explanation is a bit difficult to me.
Thanks again.
----------=========---------
Mitsuo Igarashi
mitsu5 AT ruby DOT famille DOT ne DOT jp


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -