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/
