This is the mail archive of the cygwin@cygwin.com 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 ...)


----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
> > 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?)

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.

Rob

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


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


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