Re: make -q and maintainer-makefile issues?

[Charles Wilson]

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

CHECK_NOTES
Description: Text document