gettext packaging bug?

Charles Wilson
Wed Jun 12 19:09:00 GMT 2013

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:


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):

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

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


-------------- next part --------------
Packaging hints for binary package distributors

Although the source of the gettext package comes as a single package,
I recommend that in distributions of binary packages the installed files
be split into two packages:

        Contents: Runtime libraries and programs.
        Audience: Anyone who wants to run internationalized programs.

        Contents: Tools and documentation for developers and translators.
        Audience: Anyone who wants to develop or localize internationalized
                  programs, i.e. developers and translators.
        Dependencies: requires gettext-runtime.

The 'gettext-runtime' binary package is much smaller than the 'gettext-tools'
binary package (420 KB versus 5.5 MB). I recommend to include it in the default
installation list, like GNU 'coreutils'; in fact, the runtime programs are
utilities for sh programs.

The 'gettext-runtime' binary package can be installed by doing

      cd gettext-runtime
      make install

The 'gettext-tools' binary package can be installed by doing

      cd gettext-tools
      make install

If you want to install both at the same time, you simply do at the toplevel

      make install

The precise split between gettext and gettext-tools is according to the
following file list.




      $prefix/lib/libintl.*               (not installed on glibc systems)
      $prefix/lib/charset.alias           (not installed on glibc systems)
      $prefix/share/locale/locale.alias   (not installed on glibc systems)
      $prefix/include/libintl.h           (not installed on glibc systems)





      Everything else, i.e. currently:

      $prefix/lib/  (only installed on glibc systems)
      $prefix/share/gettext/gettext.jar   (only installed if gcj is not present)
      $prefix/share/gettext/archive.dir.tar.gz   (only installed if --without-git specified)
      $prefix/share/gettext/archive.cvs.tar.gz   (only installed if --with-cvs specified)

Java support:

If GNU gcj is available at build time, two programs will be built as native
and the gettext-tools package will therefore have a runtime dependency to

If GNU gcj is not available at build time but another Java implementation is
available instead, the two programs will be compiled to Java bytecode only:
and the gettext-tools package will therefore have a runtime dependency to
the Java virtual machine (Sun Java2, IBM Java2, GNU libgcj.jar, or other).

C# support:

For C# support, one of pnet or mono must be available at build time; it must
also be available at run time. If you have both available, choose the desired
one through the configure option. Note there is no interoperability currently
between pnet and mono: Programs compiled with pnet don't run with mono, and
vice versa.

More information about the Cygwin-apps mailing list