Mail Archives: cygwin-apps/2001/12/13/12:55:59
I've updated gettext to version 0.10.40, and (as with ncurses) munged it
around to use auto-import/export. This way, I don't have to modify
libintl.h. Previously, the fact the "our" gettext headers were
different meant that many folks had difficulties building software that
used gettext, because unless '--with-included-gettext' was specified
they got a strange mix of "use local copy of libintl.h, but link against
system cygintl.dll" Which didn't work (easily). So folks had to either
use-included-gettext, or link statically against the system libintl.a.
Arguably, this is a bug in the OTHER package, not gettext itself. But,
it exists and it is real. This change --to cygwin's gettext package--
(should) eliminate the problem.
However, this means that the new gettext dll is not backward compatible
with packages linked against the old dll So, I've split it up into two
packages, and provided a "compatibility' package:
gettext: contains everything except the dll
libintl1: contains cygintl-1.dll (the new dll)
libintl0: contains cygintl.dll (the old dll)
If I go ahead with this, then the maintainers of the following packages
need to update their setup.hints to require "libintl0" instead of gettext:
sharutils vim nano mutt wget
We can expect people to update gettext -- without installing libintl0 --
and reporting a "bug" to the list. I don't know how to deal with this,
other than perhaps to add a (not real) dependence on libintl0 in
gettext's setup.hint to force an install...
What do you all think? Is it okay to make this change, and should I
*lie* about gettext's actual requires: in order to force folks to
How should we handle this sort of thing in the future, when setup.hints
of OTHER packages need to be updated, but the one forcing the change
(me, in this case) is not the maintainer of those other packages?
Oh yeah: link
- Raw text -