Mail Archives: cygwin/2006/04/10/15:31:09
On Mon, Apr 10, 2006 at 02:52:04PM -0400, Igor Peshansky wrote:
>On Mon, 10 Apr 2006, Brian Dessent wrote:
>> Igor Peshansky wrote:
>>>If GetCommandLine lives in libcygwin.a, then programs linked on older
>>>versions of Cygwin will not link that function in, and thus won't work
>>>with the new DLL. Programs linking with the new version of Cygwin will
>>>have that function, but due to API changes, may not work with older
>>>DLLs. Or am I missing something?
>>
>>It should work out like this:
>>
>>Linked against <1.5.20, Run against >=1.5.19: calls kernel32's GCL()
>>and won't work
>>
>>Linked against <1.5.20, Run against <1.5.19: calls kernel32's GCL() but
>>the win environment exists, success
>>
>>Linked against >=1.5.20, Run against any version: calls libcygwin's
>>static GCL(), which works in any circumstance
>
>I'm worried about the case
>
>Linked against >=1.5.20, Run against <=1.5.19: calls libcygwin's static
>GCL, which works, but fails because 1.5.20 (or 1.5.21, etc) has an
>extra API function that now gets invoked by the code, but is missing
>from 1.5.19 and earlier -- BOOM.
>
>IOW, the infamous "Procedure entry point ... couldn't be found" popup.
So you're thinking that a program which has had no other changes, and
hasn't been recompiled, is going to somehow pull in newer functions from
cygwin1.dll?
Please provide examples of how that could happen.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -