This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
RE: rebase problem for cygcurl-2.dll still existing?!
- From: "Robert Collins" <robert dot collins at syncretize dot net>
- To: "'Nicholas Wourms'" <nwourms at netscape dot net>,"'Jason Tishler'" <jason at tishler dot net>
- Cc: <cygwin-apps at cygwin dot com>
- Date: Wed, 17 Jul 2002 22:16:28 +1000
- Subject: RE: rebase problem for cygcurl-2.dll still existing?!
> -----Original Message-----
> From: cygwin-apps-owner@cygwin.com
> [mailto:cygwin-apps-owner@cygwin.com] On Behalf Of Nicholas Wourms
> Sent: Wednesday, 17 July 2002 10:09 PM
> To: Jason Tishler
> Cc: cygwin-apps@cygwin.com
> Subject: Re: rebase problem for cygcurl-2.dll still existing?!
>
>
> Jason Tishler wrote:
>
> >>Is that a deficiency of cygwin as a whole, or just related
> to the way
> >>my DLL was built?)
> >>
> >
> >Cygwin's fork() attempts to load DLLs in the child in the
> same location
> >as in the parent. If it fails, then the child aborts.
> >
> Other than the lack of someone writing the code, is there any
> reason why
> fork() can't automagically try another location? Is this
> even possible?
> Or does it go against the way Cygwin/Windows works?
It goes against the way fork works.
Take a pointer foo with value bar. After fork, *foo must equal *foo
before the fork. If bar points into a dll, and the dll is mapped
somewhere else, then after fork *foo != *foo before the fork.
Rob