Mail Archives: cygwin/2006/04/10/16:12:49
On Mon, Apr 10, 2006 at 03:55:02PM -0400, Igor Peshansky wrote:
>On Tue, 11 Apr 2006, Christopher Faylor wrote:
>
>> 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?
>
>Huh? That's the point -- it *has* to be recompiled
See all of the uses of the word "linked" above? It has to be relinked,
not recompiled.
>> Please provide examples of how that could happen.
>
>I compile program A (which uses GCL) under 1.5.18 and release it. It
>doesn't work properly on 1.5.20+ (because it calls the kernel's GCL). I
>then recompile it under 1.5.20 to pull in the new libcygwin.a. However,
>this also pulls in whatever new functions are in cygwin1.dll, so that
>program A now doesn't work with <1.5.20. Am I missing something?
I was only talking about the simple act of relinking a program, not
recompiling everything. However, it's unlikely that a program which has
had no other changes is going to pull in a new function from the cygwin
DLL even after recompiling. The only way I can think of that that could
happen is if a macro in a header file changed or we introduced a
backwards compatibility redirect in libcygwin.a.
A program which is using "WinMain()" or GetCommandLine is not likely to
be using linux functionality very heavily. It's likely not going to be
using configure to detect the existence of new functions which will
cause the program to use new the functions.
So I think this scenario is pretty unlikely even if you do recompile.
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 -