Mail Archives: cygwin/2002/10/18/13:14:16
Rolf Campbell wrote:
> Found 2 matches for cygintl-2.dll.
>
> libintl2/libintl2-0.11.2-2 GNU Internationalization runtime library
> libintl2/libintl2-0.11.5-1 GNU Internationalization runtime library
>
> I had 0.11.5-1 installed (I reinstalled it just to be sure). It still
> didn't work.
>
> I tried backing out to 0.11.2-2, and it worked fine.
>
> I'm running the dumper.exe from cygwin 1.3.13-2.
Thanks for the tip -- you are correct that the binary interface of
libintl changed between 0.11.2 and 0.11.5 (I didn't notice earlier
because it was NOT flagged in the NEWS or ChangeLog...Grrrr....and the
problem only shows up rarely. Most apps don't use the foo__ aliases.)
Unfortunately, I can't fix this. Bruno changed the export aliases from 'foo__"
to "libintl_foo" -- but he didn't bump the 'LTV_CURRENT' variable in intl/Makefile.in.
This is his mistake, and I suppose for the official cygwin release I *could*
1) repackage gettext-0.11.2-2's cygintl-2.dll as 'libintl2'
2) bump gettext-0.11.5's LTV_CURRENT to '5'
(LTV_AGE = 2, so dllnum = 3)
3) respin gettext-0.11.5-2 with a new 'libintl3' package containing cygintl-3.dll.
But that means that the "official" gettext package on cygwin will build differently than
the gettext code placed into projects by the 'gettextize' command -- and worse, Bruno
*specifically* says right in the relevant Makefile:
> # Before making a gettext release, the gettext maintainer must change this
> # according to the libtool documentation, section "Library interface versions".
> # Maintainers of other packages that include the intl directory must *not*
> # change these values.
I think "gettext maintainer" is *not* me, but Bruno.
So, we're left with an "updated" DLL that *may* break existing apps, and
they need to be recompiled against the new library. Blech.
This conflict only happens if the app in question, for whatever reason,
uses the internal alias "foo__ / libintl_foo" instead of directly
calling "foo". (in dumper's case, 'dcgettext__' instead of just
'dcgettext') I'm not sure what triggers using the alias; it **seems**
to be triggered by configuring the application with
'--with-included-gettext' -- but if THAT's the case, then the app
shouldn't be using MY gettext DLL at all!; instead it (dumper.exe, in
this case) should be using its own local convenience/staticlib version
of libintl. That's the whole point of the aliased names...
Given that it took a month for this problem to surface, I surmise that
not many apps will exhibit this problem. Recommend that we maintain
source compatibility with Bruno's official release, and break technical
binary compatibility with earlier 'cygintl-2.dll' versions.
This means that offending programs, that *happen* to exhibit this
behavior, need to be recompiled against the newer gettext library. The
latest cygwin snapshots have been compiled against the new
cygintl-2.dll, so that takes care of dumper.exe.
If you need dumper (and not many people do), then download the latest
'cygwin-inst' snapshot and extract dumper.exe from it. It will
*probably* work ok with the 1.3.13-2 DLL, but no guarantees. In any
case, this problem will go away once 1.3.13-3 is released.
--Chuck
[still not back "for real" -- but I'm breaking my silence because
arguably, this goof is my fault. It's more complicated than that, but I
felt I needed to explain it -- and why I'm not going to respin gettext
to fix the problem]
--
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 -