This is the mail archive of the cygwin-apps 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: gettext packaging bug?


On 6/12/2013 11:13 AM, Corinna Vinschen wrote:
I was just trying to build a package on a new 64 bit Cygwin test
machine, when I encountered a missing libintl.h.  As it turned out,
I had gettext-devel installed, but not gettext.  In the 64 bit version
of gettext, gettext-devel depends on libintl8, but not on gettext, so
that's that.

Ah, that's a bug in Yaakov's packaging of gettext. On 32bit, gettext-devel requires: gettext.

However, why is libintl.h in gettext, and not in gettext-devel?

A header file belongs in the devel package if there is one, isn't it?

The upstream maintainer, Bruno Haible, strongly recommends certain conventions when packaging gettext. While we have to deviate from those recommendations somewhat for cygwin, I tried to adhere as closely as I could to them. See the attached PACKAGING file; what Bruno calls "gettext-tools" I've packaged as "gettext-devel" more or less, and what he calls "gettext-runtime" I've packaged as "gettext", with obvious exception that DLLs themselves all get their own package(s).

However, in actuality, neither Bruno's "gettext-runtime" (our gettext) nor his "gettext-tools" (our gettext-devel) really represent a "traditional" runtime-vs-devel split.

Note that this means all of the following:

/usr/lib/libintl.a
/usr/lib/libintl.dll.a
/usr/lib/libintl.la
/usr/include/libintl.h

are actually in 'gettext' and *not* in gettext-devel.

I'm open to reorganizing the gettext packaging (ignore Bruno?) but we *really* don't want to make gettext depend on gettext-devel (gettext-devel pulls in git, to make autopoint work). The other way around -- where gettext-devel requires: gettext -- could work, and in fact *is* the current practice at least in the 32bit package.


Background info:

With the release of 0.11 way back in 2002, gettext itself was reorganized into supporting libs (in addition to the pre-existing libintl) and application code. At that time, Bruno made the original packaging suggestions; I tried to explain my version of them in the cygwin README (relevant section pasted below):

0.11.2:
Between 0.10.40 and 0.11.2, there were massive changes in the
gettext package.  Much of the code for the development tools
was pulled out and placed into two additional libraries,
libgettextlib and libgettextsrc.  These are NOT for use by
outside programs, but only by the gettext tools themselves --
so the header files, static lib, and import lib are NOT
included in the binary package (this ommission is actually
*recommended* by Bruno in the PACKAGING file).
  However, in general these two support libraries are built as
shared libraries (DLLs), so the cyggettextlib-0.11.2.dll and
cyggettextsrc-0.11.2.dll files are installed.

 [*]

> Also, these
libraries are NOT versioned according to the normal libtool
method (--version-info x:y:z), but instead are versioned
using the --release 0.11.2 method.  That means that every
new release of gettext will ship new versions (0.11.3, etc)
of these two libs -- and since no package other than
gettext itself uses them, we don't need to worry about
keeping old versions around for compatibility and stuff.
  So, I've made all of the necessary changes to enable
these two libs to be built as DLLs -- which include:
  1) use the functional, not macro, form of po_gram_error
     and po_gram_error_at_line.  Otherwise, our client
     programs msg*.exe will attempt, via the macro, to
     directly access fields of the imported structure variable
     gram_pos.
       changes: src/po-lex.h src/po-lex.c
  2) provide an accessor function for the imported
     array-of-structures variable plural_table[] (otherwise
     our client programs will attempt to directly access
     elements of the table -- a no-no for auto-import).
       changes: src/plural-table.h src/plural-table.c
                src/msgfmt.c src/msginit.c
  3) pull out the getopt functions from these libraries,

[ (3) deleted because the getopt manipulations are no longer necessary
nor performed in builds of modern gettext for cygwin]

[*] didn't actually get this working in 0.11, so it had to wait until the 0.12 era, when I finally got the gettextsrc and gettextlib libraries building as DLLs (along with gettextpo), There was a slight tweak:

0.12.1:
Update to the latest release.  Also, now that libtool doesn't relink
forever, use cyggettextlib-0-12-1.dll and cyggettextsrc-0-12-1.dll.
Now, the odd thing about this is, cyggettext*-0-12-1 are PRIVATE
libraries.  Their version number will change with every new release,
but since nobody (outside of this package) is allowed to use them,
there's no need to worry about backwards compatibility and keeping
old versions around and -- you would think -- no need to put them
into their own package.

BUT.  cyggettextpo-0.dll provides the PUBLIC interface to those
two private libraries.  Thus, external packages might depend on
cyggettextpo-0.dll (which in turn depends on cyggettextlib-X-Y-Z
and cyggettextsrc-X-Y-Z, but they don't know that).  Thus,
cyggettextpo-0.dll needs to be in its own package -- AND
cyggettextsrc-X-Y-Z.dll / cyggettextlib-X-Y-Z.dll need to be with
it.  Thus, later versions of gettextpo will look like this:

  libgettextpo0 (first)
    cyggettextpo-0.dll
    cyggettextsrc-0-12-1.dll
    cyggettextlib-0-12-1.dll
  libgettextpo0 (next, but public interface gettextpo hasn't changed)
    cyggettextpo-0.dll
    cyggettextsrc-0-12-2.dll
    cyggettextlib-0-12-2.dll
  etc.

External packages keep seeing cyggettextpo-0.dll, but behind the scenes
the private library versions keep changing.  But they MUST be
distributed together with the public lib, or the whole thing breaks.

Sigh.

Hope that helps. For now, the quick fix is to add gettext to gettext-devel's requires: line on 64bit.

--
Chuck

Attachment: PACKAGING
Description: Text document


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