Michael,
On Thu, Dec 06, 2001 at 10:15:42AM -0500, Michael Hudson wrote:
> know anything about this?
>
> "no" is a perfectly acceptable answer :)
Unfortunately, yes. See below...
> building under Cygwin ends with the following error:
>
> building 'gdbm' extension
> gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -I.
>-I/cygdrive/e/Python-2.2b2/./Include -I/usr/local/include -IInclude/ -c
>/cygdrive/e/Python-2.2b2/Modules/gdbmmodule.c -o
>build/temp.cygwin-1.3.5-i686-2.2/gdbmmodule.o
> e:\buildpy\python.exe: *** unable to remap
> C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000
> 0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before
>initialization with status code 0x1
> 25901 [main] python 1292 sync_with_child: *** child state child loading dlls
> error: Resource temporarily unavailable
> make: *** [sharedmods] Error 1
The above occurs during Cygwin's fork() when the Cygwin DLL cannot
load a DLL to the same address in the child that it had in the parent.
I have seen this during Python 2.1.1 regression tests with threads
enabled.
My WAG is that during a regression test with threads enabled more
DLLs (i.e., extension modules) have been loaded (i.e., imported) into
the parent's address space. Hence, the probability of a DLL address
clash is higher than without threads enabled. Otherwise, just to be
clear, I feel that this problem has nothing to do with threads.
I have just reproduced this build problem with Python 2.2b2 too. However,
I don't believe that it is related to the particular Python version one
attempts to build. The reason that we are observing this problem now is
that very recently some packages (e.g., OpenSSL) were just updated with
their static libraries replaced by their shared (i.e., DLL) counterparts.
Hence, the probability of an address clash just increased some more.
Previously, I tried suggestion (a) from:
http://sources.redhat.com/ml/cygwin/2001-09/msg01165.html
Unfortunately, even the non-threads Python 2.1.1 failed its regression
test with this error.
Also, I searched the MSDN and found the rebase utility:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/perfutil_2z39.asp
which could possibly solve this problem. I haven't tried it yet, but
even if it does solve the problem, then people without the MS SDK will
not be able to build Cygwin Python. :,(
Solving this problem has been on my list, but I thought that I could
procrastinate until after the threads issue was resolved. Apparently,
I was wrong. And as typical with my luck, major Cygwin Python problems
are synchronized with Python releases. Sigh...
A few months ago, I did some investigation on this problem. What I
learned from adding some printfs to dll_list::load_after_fork() was
that the DLL in question was *already* remapped from the its preferred
image-base in the parent while this address was still available in
the child. This empirical evidence seems to contradict the following
source code comment:
/* It loaded in the wrong place. Dunno why this happens but it
always seems to happen when there are multiple DLLs attempting
to load into the same address space. In the "forked" process,
the second DLL always loads into a different location. */
In this case, it seems like the DLL was loaded in a "different" location
in the parent not the child.
Since this code *and* my understanding of the issues seemed tenuous at
best, I placed this one very gingerly back onto my "round tuit" list.
Any help with this problem would be greatly appreciated.
> Comment By: Michael Hudson (mwh)
> Date: 2001-12-06 05:53
>
> PS: can we add jason as a developer? then we can assign
> bugs to him <wink>.
Hmm... :,)
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/
