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