Re: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)

[Jason Tishler <jason at tishler dot net>]

On Mon, Dec 10, 2001 at 11:52:08AM -0500, Norman Vine wrote:
> Michael Hudson writes:
> >FWIW, and I don't know how much that is, all tests pass if I link _socket
> >statically.  Oh, and this is building without threads, it seems.  I'll do
> >a new build with threads and see if anything changes, but I doubt it.
> 
> GREAT IDEA !
> 
> I just rebuilt python 2.1.1 with threads and linking _socket statically
> and all seems to work :-)
> 
> === / usr / src / python-2.1.1 / Modules / Setup.local
> # Edit this file for local setup changes
> # socket line above, and possibly edit the SSL variable:
> SSL=/usr
> _socket socketmodule.c \
> 	-DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
> 	-L$(SSL)/lib -lssl -lcrypto

I just tried the above and it works.  However, it only works if one has
not fiddled around with rebasing their DLLs.

Although this is a good short-term workaround (and the one that I will
probably use when I release Python 2.2), I think that we should focus
our efforts on trying to solve this problem at its root cause -- Cygwin
fork() and DLL base address conflicts.  Otherwise, when something else
changes we will be back in the same situation.

I encourage the interested parties to try the rebase utility that I just
posted:

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

I would be interested if others can reproduce my findings and/or determine
how to rebase to fix this Python problem without having to build _socket
statically.

Thanks,
Jason

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