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

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

[Rolf Campbell]

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.

-Rolf

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com] 
> Sent: Thursday, October 17, 2002 12:32 PM
> To: cygwin@cygwin.com
> Subject: Re: Another problem using GDB
> 
> 
> On Thu, Oct 17, 2002 at 09:28:51AM -0400, Rolf Campbell wrote:
> >When I try to use dumper, I get an msgbox "The procedure entry point 
> >dcgettext__ could not be located in the dynamic link library 
> >cygintl-2.dll".
> 
http://cygwin.com/packages/

Search for cygintl-2.dll

Install that package.

cgf

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


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

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

[Charles Wilson]

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/