Sorry for submitting this in the 11th hour, but this patch
re-enables clean building under Cygwin.  See the following
for details:

    http://cygwin.com/ml/cygwin/2001-12/msg00409.html

Unfortunately, this patch is only a build workaround and
does *not* solve the root cause which is Cygwin's problem
with DLL address clashes during fork().  Hopefully, a yet to
be instituted rebase tool will solve this problem for real.
See the following for details:

    http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html

Logged In: YES 
user_id=6380

Michael, can you review this ASAP? If not, please assign to
Tim.

Logged In: YES 
user_id=6656

Well, it lets Python build, but the resulting Python doesn't
work all that well.

I've just noticed that linking _socket statically seems to
cure the problem.

Can we have a few more days to fiddle with this?  I wouldn't
recommend applying this patch at this stage.

Logged In: YES 
user_id=6380

Sure.  While the release candidate is officially scheduled
for Wednesday this weel, I think it'll actually be Friday.

Logged In: YES 
user_id=6656

I'm rejecting this.  Linking _socket statically is a better
workaround until the issue actually gets sorted out at the
cygwin end.

Jason, feel free to complain if you think this isn't the
right thing to do.

Logged In: YES 
user_id=86216

I'm not happy with my workaround, but I'm not happy that
Python will not build OOTB under Cygwin until the fork()
issue gets resolved.  Choose your poison!

Logged In: YES 
user_id=86216

mwh wrote:
> Jason, feel free to complain if you think this isn't
> the right thing to do.

I guess that I would like to complain and reopen this
issue. :,)  I cannot build a Python 2.2.1 with threads
under Cygwin without this patch even though I'm using
Michael's static _socket workaround.  This is due to the
Cygwin fork() problem with DLL base address conflicts
that are triggered by importing many modules during the
setup.py run.  Similar problems can also be caused by
regrtest.py.

Even after my rebase patch is accepted into Cygwin's
setup.exe, I feel that patch will still be necessary.
This is because during the build process the shared
extension (i.e., DLLs) will not be rebased yet.  Hence,
the potential for DLL base address conflicts will exist.

One way to obviate this patch is to push the rebase
functionality into Cygwin's ld.  Unfortunately, I don't
think this is likely to happen.  Another possible way,
is to use the yet to be defined and implemented unload
module functionality:

http://mail.python.org/pipermail/python-dev/2001-December/019028.html

I have refreshed the patch against current CVS for
convenience.  Can this patch be accepted this time?

Logged In: YES 
user_id=6656

I can't test cygwin any more.  Is there anyone who can?  I
know Tim can, but I'm not sure this is worth his time.

If you're just looking for someone to check stuff in, I can
do that, or we can add Jason as a developer & then he can do
it (gets my vote!).

Logged In: YES 
user_id=6380

Giving Jason checkin permission is probably the best
solution here.

Logged In: YES 
user_id=6656

Jason, this is now your problem...

Logged In: YES 
user_id=86216

Can I check this in?  Please see my comments from
2002-04-30 11:53 for my reasoning.

Logged In: YES 
user_id=6656

Uh, yeah.  It's not going to affect any platform other than
cygwin is it?

Logged In: YES 
user_id=86216

This patch will not affect any platform except for Cygwin.

Logged In: YES 
user_id=86216

Committed as setup.py 1.87.

Logged In: NO 

Looks OK to me.  (--Guido, not logged in to SF.)

Logged In: YES 
user_id=86216

On Thu, Feb 20, 2003 at 01:50:40PM -0500, Guido van 
Rossum wrote:
> Is this in current CVS on the 2.2.x branch?  If not, it should 
be.

Per Guido's request, I am back patching this to the 2.2.x
branch.

Logged In: YES 
user_id=86216

Committed as setup.py 1.73.4.15.