This is the mail archive of the
mailing list for the Cygwin project.
Re: [RFC] an alternative to rebasing
- From: Steven O'Brien <steven dot obrien2 at ntlworld dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 6 Aug 2002 09:07:41 +0100
- Subject: Re: [RFC] an alternative to rebasing
On Mon, Aug 05, 2002 at 12:41:44 -0400, Jason Tishler wrote:
> I'm sorry to report that your patch does not fix the following rebase
> Specifically, I'm getting the following:
> $ make
> building 'gdbm' extension
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -I.
> -I/tmp/python-2.2.1-1/./Include -I/usr/local/include -IInclude/ -c
> /tmp/python-2.2.1-1/Modules/gdbmmodule.c -o
> C:\cygwin\tmp\python-2.2.1-1\build\python.exe: *** unable to remap
> C:\cygwin\bin\cygcrypto.dll to same address as parent -- 0x420000
> 8 [main] python 1548 sync_with_child: child 2772(0x100) died
> before initialization with status code 0x1
> 9652 [main] python 1548 sync_with_child: *** child state child
> loading dlls
> error: Resource temporarily unavailable
> make: *** [sharedmods] Error 1
I've looked into this, and the problem now is with the imagebases of the
python dlls. The makefile is linking them with
"--enable-auto-image-base" and you will find that at least two of these
Now that *should not* pose a problem if we had a rock-solid fork()
implementation, but my patch is just a work-around, not a proper fix.
However, --enable-auto-image-base is deprecated in cygwin anyway,
because it may mean that a dll is given an image base that clashes with
cygwin1.dll, which should never be relocated (IIRC according to the
mailing list archives of last year).
So, you should remove the --enable-auto-image-base flag, then your dlls
will all get the default image base of 0x10000000, and cygwin with my
patch is able to load and fork without problem!
BTW I fully agree with Rob Collins that an effective rebase tool will
give measurable performance improvements to cygwin apps and so this
patch is not strictly an alternative to rebasing, but I think it is
still a sensible change to the fork() implementation. This is because
rebase should be an option to improve performance, not a necessity to
Are there any cygwin regression tests that I can use to look for any
undesirable side-effects of my patch?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html