[Distutils] Cygwin Python Distutils Build Problem

Thu Feb 22 04:52:03 2001

Jason Tishler wrote:
> 
> On Wed, Feb 21, 2001 at 03:42:04PM +0100, M.-A. Lemburg wrote:
> > I don't want distutils to go into the beta with this known
> > problem. The patch that you posted seems to be the way to go,
> > so I am very much for putting it into the core unless is breaks
> > something else which doesn't seem to be the case.
> >
> > Anyway, please post the patch and a summary of the problem to
> > distutils -- maybe Rene knows more about this.
> 
> Marc Lemburg recently committed a patch to facilitate the building of
> his mx Extensions under Cygwin.  I have attached his patch as the first
> attachment for easy access.  See the following for details, if interested:
> 
>     http://sourceforge.net/patch/?func=detailpatch&patch_id=103868&group_id=5470
> 
> Unfortunately, this patch breaks the Cygwin Python build.  Specifically,
> the standard (shared extension) modules no longer build.  See the second
> attachment for details, if interested.
I think the default compiler if the platform is not found in the
dictionary,
is 'unix'.
So it might be better to use "cygwin.*":"unix" instead of
"cygwin.*":"cygwin".
I wrote cygwinccompiler.py to handle cygwin for MSVC built Pythons,
but for a Cygwin built Python it seems more natural to use
unixccompiler.py .
(The option help describes "unix" as "standard UNIX-style compiler"
and for a Cygwin Python and gcc this is the right description. )

> 
> Being very inexperienced with distutils, I humbly offered the following
> WAG patch which corrected the Cygwin Python build problem.  The purpose of
> this patch is to (re)enable distutils to use the Makefile variables such as
> CCSHARED, LDSHARED, etc. when building shared extensions under Cygwin just
> like on all other UNIXes.  Please see the third attachment for details.
> 
> We have the following questions:
> 
>     1. Is my patch the best way to resolve this issue?
It is a possible way, but using unixccompiler is probably better.
 
>     2. The current cygwinccompiler.py (around line 97) has some hardcoded
>        gcc options (i.e., using -static instead -shared) that appear to
>        be out of date.  Should these be revisited too?
Some of these option were needed as workarounds for several bugs in the
versions of gcc I tested. (There was last year a version of gcc2.95
which
tried to link pythonXX.dll instead libpythonXX.a, this is the reason for
the -static option.)
We could use the version information to decide if using for an older gcc
the hardcoded option or for a newer something generic.
But then we should have a way to find out all of the version
information,
currently you get 2,95,2 for 2.95.2-X. (And at least the first versions
of
2.95.2 had some bugs. So how find out X?)

> 
> Hopefully, more knowledgeable people can help us resolve these issues
> before the first beta.
> 
> Thanks,
> Jason
> 
> 
> Subject: Re: [Distutils] Beta-release of installers for mx Extensions
> Date: Mon, 19 Feb 2001 17:10:03 -0500
> From: Jason Tishler <Jason.Tishler@dothill.com>
> To: "M.-A. Lemburg" <mal@lemburg.com>
> 
> Marc,
> 
> On Mon, Feb 19, 2001 at 05:49:28PM +0100, M.-A. Lemburg wrote:
> > Great :-) If you're the right person to ask, I have a question
> > about sys.platform on cygwin: if not absolutely necessary, I'd
> > suggest removing the version number and platform ID (nt, 98)
> > in sys.platform.
> >
> > This information is normally not needed since cygwin tries
> > to provide a posix subsystem. If it is needed, I'd suggest taking
> > a look at platform.py (available on my Python Pages) and
> > adding cygwin support to it.
> 
> I will respond to the above shortly, but please see below...
> 
> > > Jason has been monitoring the py-devel list and I try
> > > to read it over the web on at least a semi-regular basis
> > > for potential Cygwin related issues.  I monitor the distutils list
> > >
> > > Feel free to continue to ask Cygwin related questions
> > > and or request beta testing for Cygwin compatability
> > > in the future.
> >
> > See above ;-)
> >
> > I have checked in the patch in a slightly different form.
> > Could you check whether it now defaults to cygwin for cygwin
> > compiler Pythons ?
> 
> Your patch broke the building of the standard (shared extension) modules
> under Cygwin.
> 
> For example in 2.1a2, we had the following:
> 
> ..
> ./python.exe ./setup.py build
> running build
> running build_ext
> building 'struct' extension
> creating build
> creating build/temp.cygwin_nt-4.0-1.3.0-i686-2.1
> gcc -g -O2 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -I. -I/home/jt/src/Python-2.1a2/./Include -IInclude/ -I/usr/local/include -c /home/jt/src/Python-2.1a2/Modules/structmodule.c -o build/temp.cygwin_nt-4.0-1.3.0-i686-2.1/structmodule.o
> creating build/lib.cygwin_nt-4.0-1.3.0-i686-2.1
> gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin_nt-4.0-1.3.0-i686-2.1/structmodule.o -L. -L/usr/local/lib -lpython2.1 -o build/lib.cygwin_nt-4.0-1.3.0-i686-2.1/struct.dll
> ..
> 
> Now we have the following:
> 
> ..
> PYTHONPATH= ./python.exe ./setup.py build
> running build
> running build_ext
> building 'struct' extension
> creating build
> creating build/temp.cygwin_nt-4.0-1.3.0-i686-2.1
> gcc -mcygwin -mdll -O -Wall -I. -I/home/jt/src/PythonCvs/./Include -IInclude/ -I/usr/local/include -c /home/jt/src/PythonCvs/Modules/structmodule.c -o build/temp.cygwin_nt-4.0-1.3.0-i686-2.1/structmodule.o
> writing build/temp.cygwin_nt-4.0-1.3.0-i686-2.1/struct.def
> creating build/lib.cygwin_nt-4.0-1.3.0-i686-2.1
> gcc -mcygwin -mdll -static -s build/temp.cygwin_nt-4.0-1.3.0-i686-2.1/structmodule.o build/temp.cygwin_nt-4.0-1.3.0-i686-2.1/struct.def -L. -L/usr/local/lib -lpython2.1 -o build/lib.cygwin_nt-4.0-1.3.0-i686-2.1/struct.dll
> /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/../../../../i686-pc-cygwin/bin/ld: cannot find -lpython2.1
> collect2: ld returned 1 exit status
> WARNING: building of extension "struct" failed: command 'gcc' failed with exit status 1
> ..
> 
> During compilation, we now are/have:
> 
>     missing -DUSE_DL_IMPORT option (i.e., CCSHARED variable)
>     extraneous -mcygwin -mdll options
> 
> During linking, we now are/have:
> 
>     missing -shared -Wl,--enable-auto-image-base options
>     extraneous -mcygwin -mdll -static -s options
> 
See above why some of these options are there. I also have to confess I
am not
a specialist with cygwin. If there are other better options (and run
also with
last years version of gcc) then try it and provide a patch for it.

> If I use the latest CVS but downgrade Lib/distutils/ccompiler.py to
> 1.37, then the build succeeds.
1.37 is using unixccompiler.py and 1.38 cygwinccompiler.py.
 
> I'm willing to help you resolve this problem, please let me know how I
> can help.
> 
> Thanks,
> Jason

Kind regards
Rene Liebscher