[Distutils] Cygwin Python Distutils Build Problem

[M.-A. Lemburg]

Rene Liebscher wrote:
> 
> 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. )

If that works, I can fix this easily. Jason ?

Note that I'll be more or less offline starting later today (for two
weeks), so if this doesn't get settled today, I would appreciate if 
someone else could make the checkins. Thanks.
 
> >
> > 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?)

Oh boy...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/