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