This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
There have been some recent posts on python-list@ regarding whether or not Cygwin Python should be built with a shared (i.e., DLL) Python library or a static one. Note that Cygwin Python currently uses a DLL library like the Win32 one. Does anyone have compelling reasons why Cygwin Python needs a static library? If so, then I will consider submitting a patch to Python CVS to enable this for Cygwin. Unfortunately, it will be difficult to fit this cleanly into the Python Unix build infrastructure due to the extra steps required to build an executable that exports symbols with the current Cygwin binutils. See attached for more details, if interested. Thanks, Jason
--- Begin Message ---
- From: Jason Tishler <jason at tishler dot net>
- To: Alex Martelli <aleax at aleax dot it>
- Cc: python-list at python dot org,Martin v. Löwis <loewis at informatik dot hu-berlin dot de>
- Date: Mon, 06 May 2002 12:59:22 -0400
- Subject: Re: Creating C modules for Python under Cygwin
- References: <3CD41CC4.5752F30C@wag.caltech.edu><j43cx6ilpq.fsf@informatik.hu-berlin.de> <20020506131744.GD1668@tishler.net><mailman.1020694211.2354.python-list@python.org><pNwB8.9120$zW3.232547@news1.tin.it>
On Mon, May 06, 2002 at 02:53:09PM +0000, Alex Martelli wrote: > Martin v. Löwis wrote: > > I think this is what Alex had in mind. > > Alex doesn't understand the details of Cygwin, and dlltool in particular, > well enough to be certain, but it sure looks something like what I was > saying should be doable, yes. > [snip] OK, I got it to work. My previous procedure was incorrect because it did not get python.exe to export any symbols. The new (still quick and dirty) procedure is as follows: $ configure --disable-shared $ make python.exe # [1] $ mkexp.sh # [2] $ make # [3] Notes: [1] make will stop after python.exe is built but before the shared extensions are. [2] Rebuild python.exe to export all appropriate symbols. The attached shell script, mkexp.sh, just blindly follows the procedure used by Cygwin PostgreSQL to export symbols from an executable. I admit to not fully grokking this procedure (yet). Additionally, there may be better, more modern ways (i.e., gcc -shared) of accomplishing the same results. I will investigate further. [3] Continue make to build the shared extensions. A Cygwin Python with a static Python library built with the above procedure successfully loads shared extensions and passes all regression tests. I intend to submit a patch to Python CVS with a clean version of the above. However my motivation would be greater, if I actually knew of someone who is really interested in this functionality. Is there anyone? Thanks, JasonAttachment: mkexp.sh
--- End Message ---
Description: Bourne shell script
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |