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
Message-ID: <3BFBEDA2.5050003@ece.gatech.edu>
Date: Wed, 21 Nov 2001 13:08:34 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: Corinna Vinschen <cygwin AT cygwin DOT com>, cygwin AT sources DOT redhat DOT com
Subject: Re: cygintl.dll missing
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>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Collins wrote:


>>Yeah, I'm surprised, too.  Vim requires gettext in
>>
> setup.hint/setup.ini
> 
>>so clicking on vim should activate gettext as well.
>>
> 
> It will. What is probably happening is that folk are clicking on gettext
> until it is selected, and then clicking on vim, which means that they
> have selected the prev gettext version.


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.

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? 
  In classic libtool versioning, let's say 35p1-2 is version 2:3:1. 
According to http://www.cl.cam.ac.uk/texinfodoc/libtool_6.html, when we 
add to the interface, we should increment c and a, but set r to 0. 
Therefore, 38's revision number is 3:0:2 (I'm ignoring the -36 and -37 
releases).

However, under the windows versioning scheme, the DLL name is 
"cygfoo-$(c - a).dll"  -- that is, the version number indicates the 
earlist interface supported by the DLL:

35p1-2:  cygintl-$(2 - 1).dll == cygintl-1.dll
38:      cygintl-$(3 - 2).dll -- cygintl-1.dll

---> no versioning change (since cygintl was originally released without 
versioning info, I'm not going to uselessly add versioning information 
until there is a CHANGE in that info.  So, right now, 35p1-2 AND 38 
still contain merely "cygintl.dll"

In most cases, these two dll's are interchangeable -- UNLESS one 
actually USES the added interfaces.  Like bind_text_whatever.  This is a 
problem that really just can't be solved on the windows platform -- 
unless you want to revision EVERY release of a DLL differntly ( e.g. 
don't use the $(c - a) thing, but use $(c)-$(r)-$(a) instead.)  But 
then, given the limitations of the windows runtime loader, you'd really 
be better off not doing DLL's at all and just linking everything 
statically. :-P

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.

--Chuck



--
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/