This is the mail archive of the
mailing list for the Cygwin project.
Re: rebase problem for cygcurl-2.dll still existing?!
Earnie Boyd wrote:
I would except that process handling and memory management are not in my
areas of expertise. My intent was only for a brief elaboration on the
previous comment and an inquiry as to why it isn't another way. I'm
planning to look more into this area of the dll later on this year, but
I doubt that I could just look at the code for an hour and instantly
understand why it is one way and not the other. Just like Charles, I've
got other commitments which prevent me from studying the code and the
way it interacts within the MS environment 24x7. So I might contend
that, while your reply might be a valid one, my question is still a
Nicholas Wourms wrote:
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?
The correct answer to this question is "Use the source, Luke" (tm).