X-Spam-Check-By: sourceware.org
Date: Tue, 11 Apr 2006 11:00:58 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin backwards compatibility break with WinMain and     GetCommandLine (was Re: WinMain() not getting cl...)
Message-ID: <20060411150058.GB14895@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20060404184447 DOT GA4824 AT tela DOT daveroth DOT dyndns DOT org> <20060410013414 DOT GA20557 AT trixie DOT casa DOT cgf DOT cx> <Pine DOT GSO DOT 4 DOT 63 DOT 0604100927270 DOT 20193 AT access1 DOT cims DOT nyu DOT edu> <20060410173850 DOT GA19752 AT trixie DOT casa DOT cgf DOT cx> <Pine DOT GSO DOT 4 DOT 63 DOT 0604101352460 DOT 20193 AT access1 DOT cims DOT nyu DOT edu> <443AA212 DOT DF9AB154 AT dessent DOT net> <Pine DOT GSO DOT 4 DOT 63 DOT 0604101447170 DOT 20193 AT access1 DOT cims DOT nyu DOT edu> <20060411141921 DOT GA15620 AT trixie DOT casa DOT cgf DOT cx> <Pine DOT GSO DOT 4 DOT 63 DOT 0604101550550 DOT 20193 AT access1 DOT cims DOT nyu DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.63.0604101550550.20193@access1.cims.nyu.edu>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/