rebase problem for cygcurl-2.dll still existing?!

[Nicholas Wourms]

Earnie Boyd wrote:

>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).
>
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 
valid one.

Cheers,
Nicholas