On 8/18/2011 4:12 PM, Bruno Haible wrote:
> Charles Wilson writes:
>> 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.
Ack.
> Nevertheless, the gettext package tries to help you do that: It contains
> a file autogen.sh in the tarball,
Yes, that was what I was using to re-autotool (preceded by an explicit
libtoolize).
> and it explains
> "This script requires autoconf-2.60..2.65 and automake-1.11.1 in the PATH."
That's the part I missed; I did look in configure for the autoconf
version you /did/ use to generate it, and ditto at Makefile.in for the
version of automake that was used. The closest I had, ready to go, was
ac-2.64+am-1.11.1 -- the standard versions for current gcc development.
And, as I said later in my original email, that appears to work...better.
> 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.
I guess I'm mostly annoyed by my bad luck. It seems that both when I
worked to create the cygwin-gettext-0.17 package, and lately with
cygwin-gettext-0.18.1.1, that the version of autoconf that cygwin was
using as the default installation, had each just implemented annoying
backwards-incompatible changes. So, autoreconf'ing was more painful
that usual -- in BOTH cases. Sucks to be me.
gettext-0.17:
# Generated by GNU Autoconf 2.61.
but I was re-autoconf'ing with 2.63, which had the following
change, that didn't play nicely with contemporaneous gnulib
.m4 files
** AC_USE_SYSTEM_EXTENSIONS no longer conflicts with an external
AC_DEFINE([__EXTENSIONS__]). This fixes a regression introduced in
2.62 when using macros such as AC_AIX that were made obsolete in
favor of the more portable AC_USE_SYSTEM_EXTENSIONS.
gettext-0.18.1.1
# Generated by GNU Autoconf 2.65.
but I originally attempted with 2.68, which introduced the
following extremely annoying behavior:
** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and
AC_RUN_IFELSE now warn if the first argument failed to use
AC_LANG_SOURCE ...
However, since I had an /opt/foo/ installation of ac-2.64+am-1.11.1,
specifically for use with gcc, I used that -- and stuff worked...better.
> Or use a version of autoconf that is not newer than the release.
Ack. Or, if libtool-2.2.x is "new enough" for my purposes on cygwin,
suppress the re-autoconf step altogether. It's not like I'm patching
gettext's Makefile.am or configure.ac files -- this time (it has been
necessary in the evil dark past, circa 0.11.x or 0.12.x)
> Or pick the
> updates from the gettext git repository.
Folks tend to get annoyed when I use bleeding-edge for libraries as
fundamental as libintl...so that's probably a non-starter. :-)
>> 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.
Hmmm...actually, I don't think it is a "bug", per se. It's really just
revealing a shortcoming of ld. ld adds -Lpaths to the search list /in
the order they appear/. The writer of the Makefile (or Makefile.in or
Makefile.am) doesn't have any way of knowing that some libraries might
need to precede others -- not due to dependencies, but simply because
the END USER wants to force one lib to be picked from a custom dir, AND
that an unwanted version of the same lib appears in the directory that
the OTHER desired libs are located.
This is really one of those "Doctor, it hurts when I do this" moments:
Don't Do That.
>> 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.
Oh. Well, there's no official cygwin-openjdk package; Yaakov at
cygwin-ports has not provided a version of it either. It appears to
require the Microsoft DirectX 9.0 SDK; cygwin's (and mingw's) w32api
package does not provide complete support for directx... I think this
is probably a non-starter.
It may be possible, from within cygwin, to use the following wrappers:
http://cygwin.com/cgi-bin/cvsweb.cgi/wrappers/java/?cvsroot=cygwin-apps
with the *windows* java SDK...but that kind of frankenbuild
(cygwin+native?) is more ambitious that I'm feeling at the moment.
>> libgettextlib doesn't actually
>> reference any of the DATA items exported by the libncurses DLL:
>
> 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.
Well, the cygport tool handles that, as well:
1. cygport [script] prep
2. cygport [script] build
3. cygport [script] test
4. cygport [script] install
5. cygport [script] pkg
My "problem" is that a whole barrel of fun is hidden inside step #2.
> And when I make experiments, I keep all log files for later
> comparison, and write down every success or failure.
cygport does that too. Its just...waiting the two or three hours for
the build to finish (configure scripts are notoriously painful on
cygwin: 20x-60x slower than linux, on similar hardware. It has to do
with the hoops cygwin has to jump thru to emulate POSIX fork()/exec()
semantics. And configure scripts do a LOT of fork/exec'ing.)
--
Chuck
