Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com To: cygwin AT cygwin DOT com X-Injected-Via-Gmane: http://gmane.org/ Path: not-for-mail From: Charles Wilson Subject: Re: Dumper.exe doesn't work with libintl2-0.11.5-1. Was: RE: Another problem using GDB Date: Fri, 18 Oct 2002 13:13:08 -0400 Lines: 78 Message-ID: <3DB04124.7070808@ece.gatech.edu> References: <83040F98B407E6428FEC18AC720F5D732DB733 AT exchange DOT tropicnetworks DOT com> NNTP-Posting-Host: 1cust12.tnt6.atl4.da.uu.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1034961190 8917 67.192.41.12 (18 Oct 2002 17:13:10 GMT) X-Complaints-To: usenet AT main DOT gmane DOT org NNTP-Posting-Date: Fri, 18 Oct 2002 17:13:10 +0000 (UTC) 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 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/