This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
> enabled.

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:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]