This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Dumper.exe doesn't work with libintl2-0.11.5-1. Was: RE: Another problem using GDB


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]