On 8/12/2011 1:00 PM, Bruno Haible wrote: > [CCing bug-gettext and Charles Wilson] > Eric Blake wrote in [1]: >> At least cygwin still ships with >> only gettext 0.17, because all versions of 0.18 are unbuildable on the >> current cygwin. > > This is a myth, and is factually wrong. ... > * The Cygwin maintainer of gettext didn't put enough time into it. > > The other half of the diagnosis was incorrect: > > * No, gettext is not unbuildable on Cygwin.
Apparently it can be done -- provided you configure and build in a
specific way. However, it does not appear to be buildable the way I
*want* to build it.
On cygwin, we typically reautotool almost any package, as a routine part
of building it. This is mostly historical, but there are (still) good
reasons for it -- mainly having to do with the /patched/ versions of
libtool that we've commonly needed to use, and have provided by default,
on cygwin.
Also, cygport (the semi-de-facto-standard build tool for maintaining
cygwin packages) also typically forces updating gettext (in packages
other than gettext itself, naturally) to 0.17 at present, via autopoint
-V (our autopoint is hacked to re-enable the -V option).
Now, unlike earlier versions, stock libtool-2.2 was pretty good, for
native cygwin builds, so maybe we can skip updating libtool files now --
e.g. don't reautoconf or ./autogen at all. (OTOH, cygport now supports
cross builds, and good support for cross builds to cygwin targets wasn't
added to libtool until 2.4...so if I wanted to build *and test* gettext
using linux->cygwin, with a WINE test env, I'd need to update libtool to
stock libtool 2.4, if not cygwin-libtool-2.4 which adds a few bugfixes)
The following ought to Just Work(tm):
.../gettext-0.18.1.1$ libtoolize --automake --copy --force
.../gettext-0.18.1.1$ ./autogen.sh --quick --skip-gnulib
but it doesn't:
configure.ac:71: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in b
ody
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/
lang.m4:194: AC_LANG_CONFTEST is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/
general.m4:2591: _AC_COMPILE_IFELSE is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/
general.m4:2607: AC_COMPILE_IFELSE is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/m4sugar/m
4sh.m4:606: AS_IF is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/general.m4:2032:
AC_CACHE_VAL is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/general.m4:2053:
AC_CACHE_CHECK is expanded from...
gnulib-m4/include_next.m4:28: gl_INCLUDE_NEXT is expanded from...
gnulib-m4/include_next.m4:124: gl_CHECK_NEXT_HEADERS is expanded from...
gnulib-m4/gnulib-comp.m4:36: gl_INIT is expanded from...
configure.ac:71: the top level
configure.ac:71: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/lang.m4:194:
AC_LANG_CONFTEST is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/general.m4:2591:
_AC_COMPILE_IFELSE is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/general.m4:2607:
AC_COMPILE_IFELSE is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/m4sugar/m4sh.m4:606:
AS_IF is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/general.m4:2591:
_AC_COMPILE_IFELSE is expanded from...
etc etc etc
It's this sort of thing, every dadgum blasted time I try to build
gettext -- whatever the $DATE and $VERSION, that causes me to 'not put
enough time into it'.
For 0.17, it was the need to modify a bunch of the gnulib .m4 files:
- AC_REQUIRE([AC_GNU_SOURCE])
- AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
+ AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])
Not being an autoconf guru, that's what google told me to do, to fix
whatever error I originally ran into when re-bootstrapping gettext-0.17.
Now, concerning 0.18.1.1, I have run into this "warning:
AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body" issue before,
with other packages; I know how to fix it -- but it requires editing a
bunch of m4 files. It's a PITA.
Since time is limited, I spend an hour or so...and give up for another
month or seven. This is why cygwin-gettext is still 0.17.
On a wild hair, I just tried running autogen.sh with ac-2.64+am-1.11.1
first in my path, rather than ac-2.68+am-1.11.1 (don't ask why those
particular versions; it's what I had available) and that appeared to
work better...crossing fingers...seems to be MOSTLY ok...just a few
worrisome warnings in the build...and it ignored my
--with-libncurses-prefix and linked against the wrong libncurses...also,
I wanted the java stuff built as a .jar, not an .exe, so I did
--disable-native-java (but NOT --disable-java), but...no .jar.
See attached build-log (and test result summary).
Now, about this:
> * The xmlFree link error is a consequence of --disable-auto-import.
...
> But gettext's configure provides the right option to fix it. You
> only need to do "./configure --help | grep xml".
You're basically suggesting to use --with-included-libxml. But what
that demonstrates, is that gettext's internal applications can't be
linked against any external DLL unless that DLL either (a) follows the
Bruno Woe32 One True Way [that is, libintl and libiconv alone, out of
the universe of cygwin DLLs] or (b) provides a fully declspec(dllimport)
interface in its headers for exported DATA items, so that clients need
not auto-import.
Now, DLLs in case (a) are few: exactly 2. DLLs in case (b) are ALSO few
on the cygwin platform. Apparently cygxml2-2.dll is not one of them.
Neither, unfortunately, is cygncurses (vestigial and probably bitrotted
support, kept around for some future msvc effort, implements declspec
labelling in the ncurses headers, but it is not active for __CYGWIN__).
However, libgettextlib did link, successfully, against libncurses. I can
only assume that, simply by luck, libgettextlib doesn't actually
reference any of the DATA items exported by the libncurses DLL:
BC DATA
PC DATA
SP DATA
UP DATA
ospeed DATA
_nc_* stuff (these are internal symbols and probably
should not have been exported; call it
a upstream ncurses bug)
-- if it did, then it would need to auto-import them, and the link would
go boom. I don't like relying on luck...
(Downside: libgettextlib linked against the /wrong/ ncurses: it found
/usr/lib/libncurses.dll.a even tho I specifically told it
--with-libncurses-prefix=/some/other/path [I wanted to force it to use
the wide-char-enabled version]. Sigh. That's another rebuild cycle
(which takes forEVER on cygwin), after tracking down WHY it ignored me.
Plus I need to track down the details of some of the test failures.
And people wonder why cygwin-gettext doesn't get updated often.)
--
Chuck
gettext-0.18.1.1-1-compile.log.xz
Description: Binary data
gettext-runtime
===================================================================
All 1 tests passed
gettext-tools
===================================================================
1 of 326 tests failed
(18 tests were not run)
SKIP: gettext-3, -5, -6, -7, -8
SKIP: msgunfmt-csharp-1
SKIP: msgunfmt-java-1 (!! but I have gcj !!)
SKIP: recode-sr-latin-1
SKIP: recode-sr-latin-2
SKIP: lang-{objc,clisp,librep,guile,smalltalk}
SKIP: lang-java (!! but I have gcj !!)
SKIP: lang-{csharp,pascal,perl-1,perl-2,php}
FAIL: lang-tcl
gettext-3: skipped on non-glibc systems
gettext-5: skipped on non-glibc systems
gettext-6: skipped on non-glibc && non MacOS systems
gettext-7: skipped on non-glibc && non MacOS systems
gettext-8: setrlimit does not work
msgunfmt-csharp-1: skipped because csharp not available
msgunfmt-java-1: skipped because java compiler or jar not found
lang-*: in general skipped because the relevant compiler
is not found. Exceptions listed below.
lang-java: I would have expected lang-java to run?
lang-perl-1: perl package Locale::Messages is not installed
lang-perl-2: perl package libintl-perl is not installed
lang-tcl:
< «Votre commande, s'il vous plait», dit le garçon.
---
> âVotre commande, s'il vous plaitâ, dit le garâon.
Perhaps because our tcl is not pure cygwin, but rather win32ish,
and is not built with i18n support?
gettext-tools/gnulib-tests
===================================================================
[old note; unverified in the current release]: All tests fail when
--enable-relocation (the tests do not "activate" the relocation
support, but the gnulib library they link to expect it).
When not --enable-relocation (the normal case):
2 of 120 tests failed (3 tests were not run)
but 2 of the passes actually should be failures.
FAIL: test-file-has-acl.sh -- file_has_acl("tmpdir0") returned yes, expected no
This is expected on cygwin; all files always have ACLs (there are default
ones that can't be removed using cygwin setfacl).
PASS: test-copy-acl.sh -- but
coredump at line 205; also 'setfacl -d group:0 tmpfile0
setfacl: illegal acl entries'
PASS: test-copy-file.sh -- but
coredump at line 199; also 'setfacl -d group:0 tmpfile0
setfacl: illegal acl entries'
In both of these cases, I suspect the segfault is due to poor error
handling when setfacl reports an error. FWIW, the line numbers
reported seem to be off:
test-copy-acl.sh:205 'case $acl_flavor in'
test-copy-file.sh:199 'case $acl_flavor in'
I can't see those being the cause of a segfault (in bash?)
SKIP: test-mbrtowc4.sh -- no transitional chinese locale is supported
SKIP: test-mbsrtowcs4.sh -- no transitional chinese locale is supported
SKIP: test-mbsstr3.sh -- no chinese GB18030 locale is supported
FAIL: test-strchrnul.exe -- segfault (bug fixed in cygwin-1.7.10?)
