This is the mail archive of the
mailing list for the Cygwin project.
Re: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- To: "Charles Wilson" <cwilson at ece dot gatech dot edu>,"Jason Tishler" <jason at tishler dot net>
- Cc: "Michael Hudson" <mwh at python dot net>,<david_abrahams at users dot sourceforge dot net>,"Cygwin" <cygwin at sources dot redhat dot com>
- Date: Sat, 8 Dec 2001 10:08:14 +1100
- Subject: Re: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)
- References: <20011206124426.B1448@dothill.com> <3C0FB399.email@example.com>
----- Original Message -----
From: "Charles Wilson" <firstname.lastname@example.org>
> > 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
> > 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
> 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?)
Yes. There is actually a longer term solution... which is to 'rebase'
every cygwin linked .dll on a particular system to not conflict with
each other - which has to be done by setup.exe.
> Anyway, I plan to redo cyggdbm "eventually" without the
> --auto-image-base. Doing so *may* fix this problem, but I'm not
> 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/
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html