ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2001/12/13/12:55:59

Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3C18EBA9.9030102@ece.gatech.edu>
Date: Thu, 13 Dec 2001 12:55:53 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: Restructuring gettext
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)

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 
install libintl0?

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 -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019