dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)
Jason Tishler
jason@tishler.net
Wed Dec 12 05:56:00 GMT 2001
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/
More information about the Cygwin
mailing list