dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)
Thu Dec 6 10:12:00 GMT 2001
Jason Tishler wrote:
>>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
Part of the problem may be that cyggdbm.dll was built with
--auto-image-base. It was later demonstrated that this can cause
problems with fork; you're better off just letting ld assign the default
dllbase, which means that EVERY process will remap the dll at runtime.
Thus, no hardcoded conflicts. Downside: *very* slightly delay in
loading DLLs -- probably unnoticeable.
(Did I get that right, robert?)
Anyway, I plan to redo cyggdbm "eventually" without the
--auto-image-base. Doing so *may* fix this problem, but I'm not sure...
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
More information about the Cygwin