Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Date:	Wed, 21 Nov 2001 18:39:56 -0500
From:	Christopher Faylor <cgf AT redhat DOT com>
To:	cygwin AT cygwin DOT com, cygwin AT cygwin DOT com
Subject:	Re: cygintl.dll missing
Message-ID:	<20011121233956.GB22925@redhat.com>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<009f01c17214$9d03d130$3396e4c2 AT MONTEZUMA> <4 DOT 3 DOT 1 DOT 2 DOT 20011120204158 DOT 0217cef8 AT pop DOT ma DOT ultranet DOT com> <20011121103409 DOT G21630 AT cygbert DOT vinschen DOT de> <002a01c17270$1641a8f0$0200a8c0 AT lifelesswks> <3BFBEDA2 DOT 5050003 AT ece DOT gatech DOT edu> <024e01c172d0$45fce450$0200a8c0 AT lifelesswks>
Mime-Version:	1.0
In-Reply-To:	<024e01c172d0$45fce450$0200a8c0@lifelesswks>
User-Agent:	Mutt/1.3.23.1i

On Thu, Nov 22, 2001 at 08:05:38AM +1100, Robert Collins wrote:
>----- Original Message -----
>From: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
>> Well, the *real* problem here is that gettext-0.10.38-2's cygintl.dll
>> exports some symbols that gettext-0.10.35p1-2's cygintl.dll does not.
>> Therefore, 38's dll is backward compatibile with apps that use
>35p1-2's
>> DLL, but 35p1-2 is not *forward* compatible.
>
>It exports the new symbols, but what I wnat to know - why does vim use
>them? Are they used in the same #defines that previously used older
>symbols?
>
>> I don't know how to solve this problem.  The libtool versioning scheme
>> -- as mapped to the windows dll structure -- implies that the version
>> number should NOT change when symbols are ADDED to the interface,
>right?
>...
>Yes, and I still think that reasononing is correct. It means that having
>the newest .dll on the system will work for all apps linked to that dll
>name. Even linux doesn't guarantee forward compatability. (i.e. having
>an older library than a program needs won't work. Having a newer one
>will work for old binaries).
>
>...
>> So, to repeat: this illustrates a problem with gettext (more globally,
>> with dll versioning on windows) but I don't know how to solve it.
>> Except "update your gettext package". Sigh.
>
>Yup. It's a wonderful world :]. Seriously though, I don't percieve this
>as an issue. What I see as an issue is setup.exe not allowing
>package-version constraints on dependencies. And thats *my* problem :}.

I'm still not clear on how this is happening, though.  Is setup.exe checking
to see if a package exists on disk and then not automatically selecting
that package for download?  Or, is it the previously theorized situation
where someone specifically selects gettext but selects the wrong version?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -