[Un-CCing the coreutils list.] Charles Wilson writes: > Apparently it can be done -- provided you configure and build in a > specific way.
Yes, gettext can be built as documented in the INSTALL file. Only one extra option, --with-included-libxml, is needed on Cygwin. > 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. You are on your own when doing this. This is not the recommended way to build, explained in the INSTALL file. Nevertheless, the gettext package tries to help you do that: It contains a file autogen.sh in the tarball, and it explains "This script requires autoconf-2.60..2.65 and automake-1.11.1 in the PATH." > 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... It is absolutely normal that, when you attempt to use newer autoconf or automake versions than the ones listed, you have to do some legwork - either by yourself or by picking the corresponding updates from the git repository of gettext. > 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. Or use a version of autoconf that is not newer than the release. Or pick the updates from the gettext git repository. > it ignored my --with-libncurses-prefix and linked against the wrong > libncurses... This would be a bug, to be reported to bug-gettext, with enough details to let me reproduce it. > 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. The ability to build this jar depends on a Java compiler that has an option for selecting the output format (version of class file format). GCJ does not have this option; it's registered in the GCC bug tracker. The OpenJDK can be used instead in general; but I haven't tested that on Cygwin. > 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) Correct. > another rebuild cycle (which takes forEVER on cygwin) I understand that long rebuild cycles are painful, but one can get used to it, and develop techniques for managing long builds. My personal approach is to create a checklist of commands to execute and check each of the steps once it is done. And when I make experiments, I keep all log files for later comparison, and write down every success or failure. Bruno
