Re: cygintl.dll missing

[Charles Wilson <cwilson@ece.gatech.edu>]

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/